Red Hat Enterprise Linux (RHEL) is used primarily to build AWS servers. A specific example of how RHEL is used to build AWS servers involves purchasing licenses from third-party vendors like REL and also from AWS. Once an AMI is obtained from the Marketplace, the AMI is customized by injecting all organization standards.

After internal tools have been built on the AMI, that AMI is used to build AWS servers.

Red Hat Enterprise Linux (RHEL) has positively impacted the organization by helping track everything, such as how many users have access to the server, which is easy to monitor. RHEL also offers better options for downloading repositories easily, and the ability to stripe the EBS volumes has allowed for pulling more IOPS and throughput.

The impact on the team and organization has been significant, as it has helped improve application performance and backup performance. Since AWS backend is used for backups, RHEL striping has proven very useful.

By using RHEL striping, throughput and IOPS have increased, which reduced the backup completion time from fifteen to sixteen hours to just fifteen to sixteen minutes. The main reason is the backend and the striping implemented for EC2 instances.

Red Hat Enterprise Linux (RHEL) offers several valuable features, including being secure and standard, and making whatever commands are executed easier to manage. When security and standardization are considered, no other person can access those RHEL servers.

Another good aspect is that whatever is downloaded comes from the repository, and every command is tracked, including the person who entered the command. Tracking on RHEL AMIs and OS standardization is very effective.

Red Hat Enterprise Linux (RHEL) helps mitigate downtime and lower risks by using the Pacemaker role for high availability. The primary and secondary systems are managed by the Pacemaker role, which helps reduce downtime for applications.

Red Hat Enterprise Linux (RHEL) could be improved by including a better app stream module experience or simply phasing out modules in favor of straightforward version repos. Red Hat could also integrate more common tools directly or integrate EPEL more seamlessly. Additionally, enabling AI-based operational tuning for kernel parameters, file system parameters, and network stack optimization could enhance the experience.

Regarding needed improvements, simplifying the subscription and licensing would help reduce complexity in subscription management. Clear visibility of consumption and unused subscriptions and compliance is also important.

Seven years of experience have been accumulated in the current field.

Red Hat Enterprise Linux (RHEL) is stable.

Red Hat Enterprise Linux (RHEL) offers great scalability and supports very large memory.

The customer support received is good.

Red Hat Enterprise Linux (RHEL) has been the only solution used, and no switch from any other solution has occurred.

In comparing the business value of RHEL to other Linux distributions, no other Linux distributions have been used; only Red Hat Enterprise Linux (RHEL) has been utilized.

Red Hat Enterprise Linux (RHEL) systems are managed with a dedicated cloud support team that handles provisioning and monthly patching. Additionally, focus is placed on security hardening and optimizing it with cloud-init, instance tuning, and subscription activation.

Image Builder has been used, but the AMIs are not built personally. A dedicated support team handles the building of the AMIs.

A return on investment has been seen, as it has saved a tremendous amount of time.

Red Hat Enterprise Linux (RHEL) helps save time; for example, the Pacemaker role facilitates faster task completion, and it optimizes backup processes.

Regarding pricing, setup cost, and licensing, the pricing is good; however, licensing is a bit confusing.

My advice for others looking into using Red Hat Enterprise Linux (RHEL) is to be aware that subscriptions can be challenging to manage. When a server reboots, the subscription goes to open, which can lead to others consuming the subscription, creating a challenge regarding the subscription and licensing part.

Security requirements were a significant consideration in choosing RHEL in the cloud because it is not open source and is highly secure.

Red Hat Enterprise Linux (RHEL) is assessed as having a better knowledge base offered through its tuning capabilities. By better tuning, the documentation is referred to, which helps in day-to-day work.

Red Hat Enterprise Linux (RHEL) entitlement management can be confusing, as converting systems between subscription modes is not straightforward.

I would rate this review a nine out of ten.

My main use cases for Red Hat Enterprise Linux (RHEL) are primarily our websites and applications that run on top of Red Hat Enterprise Linux (RHEL) operating system platform.

What I appreciate most about Red Hat Enterprise Linux (RHEL) is the SELinux policy that has been introduced; I believe that is truly good security, although it was difficult initially to become accustomed to it. In the modern world, you don't want every user to have accessible permissions. It gives you a granular level of control over each and every file and directory, just as ACLs used to provide in the past. By using SELinux policy, you can actually secure these accesses and establish a strong security posture.

The main business problem that Red Hat Enterprise Linux (RHEL) helped us solve is automation of tasks and scalability of the business. Red Hat Enterprise Linux (RHEL) has helped reduce downtime because in modern infrastructure, you do not face out of memory issues. Red Hat Enterprise Linux (RHEL) has affected the downtime by reducing it to a minimal level; the reboots are very speedy.

I think the support for Red Hat Enterprise Linux (RHEL) can be much better; when it comes to something such as SUSE Linux, I feel those providers are doing a much better job in terms of support than what Red Hat provides. One area where Red Hat Enterprise Linux (RHEL) stability could be improved is with Ksplice; Ksplice is used for online patching. The problem I have seen with it is that it applies patches at the user level, but not at the kernel level. That was a problem in terms of our security architecture because it doesn't recognize that the patch has been installed. I evaluate the customer service or tech support for Red Hat Enterprise Linux (RHEL) as needing improvement; addressing the tickets takes a little longer and there has been a lack of consistency. Not every engineer who handles a case handles it correctly. Everybody has a different way of handling the tickets. So, the support needs to be a little bit more streamlined.

I have been using Red Hat Enterprise Linux (RHEL) for the past three years.

My assessment of Red Hat Enterprise Linux (RHEL)'s stability and reliability once it is deployed in production and maintained is that it's straightforward, but there's a huge functionality and learning curve. We started using it and actually understood the reason why Red Hat has implemented it and the level of granularity in terms of security posture that it provides. We understood that it's doing a really good job.

I assess the stability, availability, and reliability of Red Hat Enterprise Linux (RHEL) as pretty stable and very reliable.

Red Hat Enterprise Linux (RHEL) has crashed or failed here and there, but there were some settings that needed to be changed. We make sure that we match those parameters.

Red Hat Enterprise Linux (RHEL) scales to my needs pretty much up-to-date.

The support from a competitor I've used is Oracle. My experience with Oracle support is that Oracle on-premises support, what it provides with Oracle Enterprise Linux, performs very well, and many of our customers believe that something from Oracle is more secure. When they compare Oracle with Red Hat, it has a much better support system and a much more secure posture than what we get.

I evaluate the customer service or tech support for Red Hat Enterprise Linux (RHEL) as needing improvement; addressing the tickets takes a little longer and there has been a lack of consistency. Not every engineer who handles a case handles it correctly. Everybody has a different way of handling the tickets. So, the support needs to be a little bit more streamlined.

My experience with the deployment of Red Hat Enterprise Linux (RHEL) has been smooth because back then we were on-premises and all our information used to be on-premises, rather than run them completely as we do now.

I have evaluated a couple of operating systems including Ubuntu, Oracle Linux, SUSE, and then came to Red Hat Enterprise Linux (RHEL) because Red Hat is considered the pioneer.

I have considered replacing Red Hat Enterprise Linux (RHEL) with another solution; specifically Oracle Linux.

If I were to switch, I would consider factors such as security and support.

We are currently considering using the Ansible Automation Platform for configuration and patching; we are using a manual approach and a little bit of Ansible here and there, but not fully deployed an Ansible Automation Platform or command line approach. But today I had the experience in the lab with the Ansible Automation Platform. That looks truly promising. I hope to get a chance to do a proof of concept and show my company that this is the product we can use in the future.

I have used the in-place upgrades to migrate machines to a newer release of Red Hat Enterprise Linux (RHEL); I used LEAP which has been designed to upgrade Linux 7 to Linux 8, and it was smooth. I think that was truly good work, especially because it supports you in situations where you do patching.

The upgrade process for Red Hat Enterprise Linux (RHEL) is straightforward and we didn't have any problems.

We are planning on upgrading from Red Hat Enterprise Linux (RHEL) 6 and 7 to 8, though we do have some legacy applications that would not support it. However, other systems which are web servers or Apache, we are trying to upgrade them.

I haven't found any limitations in Red Hat Enterprise Linux (RHEL)'s security.

My assessment of the documentation offered by Red Hat Enterprise Linux (RHEL) is that Red Hat's documentation is top notch. You cannot compare that with SUSE.

My specific goals that led me to choose Red Hat Enterprise Linux (RHEL) include the security posture.

Current, I am using the standard lifecycle support add-on for Red Hat Enterprise Linux (RHEL); I think we are still sticking with the standard and haven't upgraded yet.

The advice I would give to a team considering Red Hat Enterprise Linux (RHEL) is that one of the new features that it has is promising, and everybody promises great things with new features. My overall rating for Red Hat Enterprise Linux (RHEL) is nine out of ten.

I've been using Red Hat Enterprise Linux (RHEL) for four or five years now because I had a business with my cousin. We are Red Hat Partners. Easier integration is important because most customers we work with already have Red Hat. We use Ansible for discovery, primarily for ServiceNow. We also wanted to expand into the field of Maximo asset management. One customer, a big Red Hat partner, uses IBM Maximo, but that didn't work out because I have a business with my cousin and one of his partners parted ways, so I stayed with ServiceNow.

Red Hat Enterprise Linux (RHEL) helps solve pain points related to user account servers and onboarding certain servers. It's easier to use in my opinion and less complicated, especially for Ansible discovery.

Organizations need to know what assets they have because sometimes they have assets on the network and don't know what they are. With the solution, it's easier to discover the assets, what OS is running on them, sometimes location, warranty information, and serial numbers.

Regarding security requirements and considerations in using it in the cloud, I've seen a lot of virtual machines on the network, and no one knows anything about them. As soon as you deploy Ansible, you can know exactly what servers the virtual machine is running on, whether there's a warranty, serial numbers, naming convention, and all that, which makes it easier.

For now, Red Hat Enterprise Linux (RHEL) works fine for me. When I used it in the past, I don't see what I can improve now because it works the way I want it. There aren't any additional features that I think should be included in the future since you have AI now, and I think you are up to date.

I've been using Red Hat Enterprise Linux (RHEL) for four or five years now.

Red Hat Enterprise Linux (RHEL) has helped me mitigate downtime and lower risk. When it comes to downtime, there are no worries, for example, when there's an issue or something is down, the response time is solid.

Customer service is great, and there are several certifications and lots of certification options you can get for you and your team. Red Hat Enterprise Linux (RHEL) is also worldwide, and everyone knows it.

Red Hat Enterprise Linux (RHEL) is easy. Compared to other companies, everything is there and it's easy. When it comes to price, I can say it's cheaper than certain solutions out there in Asia or overseas.

This product is not purchased on the AWS Marketplace; we're helping sell our customers with our ServiceNow migrations, so we don't push or purchase anything from AWS Marketplace. Everything about Red Hat Enterprise Linux (RHEL) is online and it's easy to become a Red Hat partner. It's not hard. My cousin had the business with us and was already a Red Hat partner. It's easy to get the certifications, and they make everything easier. Red Hat Enterprise Linux (RHEL) is what most companies use before selecting it, and it's mostly worldwide use for that. That's what my cousin and I thought when he had the business. I would say the solution is an easier option overall. My overall rating for this product is 5 out of 5.

My main use case for Red Hat Enterprise Linux (RHEL) is for the central monitoring of the operations.

Red Hat Enterprise Linux (RHEL) helps me solve pain points by enabling faster transactions and more transactions.The feature I like the most about Red Hat Enterprise Linux (RHEL) is its resilience.A huge amount of transactions benefits my organization because we use this cluster to include the performance of Red Hat Enterprise Linux (RHEL).Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risk.

Red Hat Enterprise Linux (RHEL) could be improved with frequent updates.I think frequent upgrades should be included in the next release of Red Hat Enterprise Linux (RHEL).

I have been using Red Hat Enterprise Linux (RHEL) for two years.

I would assess the stability and reliability of Red Hat Enterprise Linux (RHEL) by stating that it is very secure, reliable, and fast.I have not experienced any downtime, crashes, or performance issues with Red Hat Enterprise Linux (RHEL).

Red Hat Enterprise Linux (RHEL) scales effectively with the growing needs of my organization.I have not experienced any issues with Red Hat Enterprise Linux (RHEL).

I would evaluate customer service and technical support for Red Hat Enterprise Linux (RHEL) as good, and we have vendor coordination with them.On a scale of one to ten, I would rate customer service and technical support for Red Hat Enterprise Linux (RHEL) as an eight because it needs the streamlining of things.

Prior to adopting Red Hat Enterprise Linux (RHEL), I was using a platform from IBM initially, which was pushed into containerization.

I would describe my experience with deploying Red Hat Enterprise Linux (RHEL) as not complicated and manageable, and that works well.

I manage my Red Hat Enterprise Linux (RHEL) systems with mass provisioning and patching, and I am very satisfied with the management experience.I managed the expansion on Red Hat Enterprise Linux (RHEL) as well.

I have not really seen an ROI with Red Hat Enterprise Linux (RHEL).

My experience with pricing, setup cost, and licensing for Red Hat Enterprise Linux (RHEL) is that pricing is heavy on this.The setup cost and licensing for Red Hat Enterprise Linux (RHEL) involves a perpetual license.

The other solutions I considered before selecting Red Hat Enterprise Linux (RHEL) included open source options.What stood out to me in my evaluation process of Red Hat Enterprise Linux (RHEL) is that the main feature is security on top of the open source, and we are considering the open-source platform to be implemented.

The complexity of Red Hat Enterprise Linux (RHEL) comes from the methodology, which is complex.Security requirements were a consideration in choosing Red Hat Enterprise Linux (RHEL).My assessment of Red Hat Enterprise Linux (RHEL)'s built-in security features is that it is effective when it comes to simplifying risk reduction and maintaining compliance.My upgrade and migration plans for Red Hat Enterprise Linux (RHEL) to stay current include frequent patching and upgrades annually.I assess the knowledge base offered by Red Hat Enterprise Linux (RHEL) as good for a few use cases.The factors that led me to consider the change to Red Hat Enterprise Linux (RHEL) were stability and reliability.I would describe my experience with deploying Red Hat Enterprise Linux (RHEL) as not complicated and manageable, and that works well.I have no advice to give to other organizations considering Red Hat Enterprise Linux (RHEL). I would rate this product a nine overall.

My main use case for it is that we just support the application.

In general, it benefits our organization because it's more cost-effective. We save money, that's it.

The main point it helps me solve is that it's just a web server.

I don't have specific feedback on what works well and what Red Hat Enterprise Linux (RHEL) needs to improve on.

I cannot think of any additional features that should be included in the next release.

I have been using Red Hat Enterprise Linux (RHEL) for about eight years.

I have not experienced any downtime, crashes, or performance issues.

I assess the stability and reliability of Red Hat Enterprise Linux (RHEL) as stable.

So far, so good with how Red Hat Enterprise Linux (RHEL) scales with the growing needs of my organization. Everything is supported.

I expand usage of it every year.

I evaluate the customer service and technical support as very good.

On a scale of one to ten, I rate it a ten.

Every time we have an issue, someone is there to fix it and troubleshoot, which is why I say that.

When I joined, Red Hat Enterprise Linux (RHEL) was already selected, so that's what was there.

In my role, I have not considered other solutions in the past.

I would describe my experience with deploying it as straightforward.

We use Azure as our cloud provider.

I have not seen ROI with Red Hat Enterprise Linux (RHEL).

I don't know the exact number, so that may be because I just am not in charge of that kind of thing.

My experience with the pricing and the cost of licenses is that if you compare it to the different operating systems, it's a little bit cheaper. The support is also good as well.

Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risk.

My assessment of Red Hat Enterprise Linux (RHEL)'s built-in security features for simplifying risk reduction and maintaining compliance is a score of eight or nine.

Everything is clearly stated and listed in the documents, so it's easy for us to follow, which is what could make it better.

Security requirements and considerations were important in choosing Red Hat Enterprise Linux (RHEL) in the cloud because we are banks, so we have a lot of security regulations to follow.

When it comes to managing Red Hat Enterprise Linux (RHEL) systems for provisioning and patching, that's our wonderful part of the day, as we use it as well. The issue we have is that it's not a fixed time that we need to patch, but when we patch, the system would just stop working. This is not a direct issue from Red Hat Enterprise Linux (RHEL), but from the line.

I have been involved in some Red Hat Enterprise Linux (RHEL) system upgrades or migrations.

The upgrade migration was straightforward.

I can talk about it a little bit more by saying we just upgrade it, patch it, and reboot it. That's all.

My upgrading or migration plans for the same product are that whenever we have new items that we assess, most likely we will get it.

I assess the knowledge base offered by Red Hat Enterprise Linux (RHEL) as good.

I don't need more from it; it's good.

My advice for other organizations considering Red Hat Enterprise Linux (RHEL) is that they should take into account the cost and support, especially when talking to someone in a different segment or an old colleague.

I rate this product a ten overall.

My main use cases for Red Hat Enterprise Linux (RHEL) include maintaining a stack of servers where we perform monitoring, provisioning, certificate provisioning, and checking patch status across the servers.

The most valuable feature within my systems is Satellite. The features that I appreciate most on a daily or on-demand basis are those provided by Satellite. This feature benefits my organization by providing provisioning for every instance, as we have approximately 100 instances under Red Hat and another 20 under Ubuntu. Currently, we use a single user interface to control them all.

Red Hat Enterprise Linux (RHEL) could be improved by providing end-to-end support for customers because we are seeing that it is more distributed. For all the Red Hat services, we use Satellite, but other services are on the cloud, and some things are hybrid cloud. This means we have multiple platforms to monitor each time. Another area for improvement is the false positives. We have the Red Hat alarm system, and it is good, but it just fires and reports, sending an email every night for us to check our duties. This is really unpleasant for us.

I have been using Red Hat Enterprise Linux (RHEL) for four years.

I have experienced downtime, crashes, or performance issues seldomly. It is good and can solve 80% of problems. Sometimes I seek consultants for help to rebuild the model or to see what the root cause is. Sometimes this problem occurs many times, requiring someone to show up and thoroughly investigate it.

Red Hat Enterprise Linux (RHEL) scales with the growing needs of my organization as it is stable, and I see that with Android development. However, I think it has only increased our usage by 3%. I think it is stable and we will not decommission it, but we still compare the benefits of cloud solutions and the Red Hat solution. I have expanded usage on Red Hat because Ubuntu is an open licensing and very unmanageable, so we are trying to reallocate resources to Red Hat.

I evaluate customer service and technical support as great. My own company has a consultant who is very timely in dedicating support to our services. We can call at any time to seek urgent consultant services. Overall, it is good. We find that rebooting or rebuilding is tough for us. We want to make sure that the service is ready to use, but for some unfortunate situations that happen, we seek 24-hour support to solve the problem as soon as possible. Every second that passes represents a loss for us.

Prior to adopting Red Hat Enterprise Linux (RHEL), we were using Ubuntu, and now it depends on what this product and what this pipeline built initially. If they used Ubuntu at the beginning of the startup, we just use it. We make sure they are up, make sure they are stable, and do not care about anything else. If they use Red Hat, we just keep running with it.

I would describe my experience with deploying Red Hat Enterprise Linux (RHEL) as manageable. It is not out of control. For every server instance, we get notified, and I get an alarm at a very early time, so we can manage to replicate it. This instance has some broken files, which is helpful for the developer to debug and understand it.

When I was deploying Red Hat Enterprise Linux (RHEL), the deployment, particularly the hotfixes, is a real challenge. We have some big instances with the front-end code and back-end code in one service. We have to do this really quickly to deploy hotfixes and implement new features. We need to make sure that the code is consistent across all the services at that time. We can do the Ansible playbook, which is a very good template that we can reuse to replicate the problem.

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades or migrations, as for version upgrades, I have been involved. We still have some Red Hat Linux consultants who support us in doing the migration. I think it is helpful. The seamlessness of the process with the consultant depends on the service difficulty because sometimes everything is hard to ensure that it is correct. It depends on the project size.

I do not touch the pricing and the cost of the solution, but I think compared to some cloud costs, it is good because our team is relying on that. We just make sure that the service is up.

The other solutions I considered before selecting Red Hat Enterprise Linux (RHEL) are that in our company, we have two choices: one is Red Hat and one is Ubuntu.

My security requirements and considerations in choosing Red Hat Enterprise Linux (RHEL) include that this is our manager, and we want to have some endpoints tracking any attack and detecting the status of anything broken. My assessment of Red Hat Enterprise Linux (RHEL)'s built-in security and compliance features is that right now, I think it is simply risk reduction. I am just maintaining it. For maintaining compliance, I can say that the first priority is to keep it safe. The second priority is to keep it up. We make sure they are okay, available to use, and available to maintain. For any other new features, we do not require that. We just make sure of these two things. Beyond this point, we are seeking some cloud help.

My upgrade and migration plans to stay current with Red Hat Enterprise Linux (RHEL) are that we need to upgrade it every year, or just when you have a vulnerability, you need to come up with it and upgrade it. From my perspective, we are not doing really timely upgrading because we do not want to disturb the current pipelines.

For the knowledge base offered by Red Hat, such as the Confluence page, it is helpful. For Red Hat Enterprise Linux (RHEL), the knowledge base is helpful. I try to look up and check many of those pages, and they give me detailed ideas on how to implement the system. Sometimes the problem is really unique, and I can get help or try to get support to formalize some questions and help us understand the solutions. I still need to seek a senior consultant's help on migration. Some documentation is outdated.

My advice to other organizations considering Red Hat Enterprise Linux (RHEL) is that if you use Java, you should use it. If you have many massive servers to maintain, a Red Hat solution with the pipeline and Satellite is beneficial. If you have some old legacy systems, you do not have to set up new labor on monitoring. I give this product an overall rating of 8 out of 10.

My main use cases for Red Hat Enterprise Linux (RHEL) are extensive, but mostly we utilize it for our clients as a base operating system.Red Hat Enterprise Linux (RHEL) solves pain points related to security patching and support.Security requirements for choosing Red Hat Enterprise Linux (RHEL) in the cloud depend heavily on the client's business. For some clients, we don't have any special regulation, but for domains such as oil and gas, there are very strict security requirements that we must meet. In most of the current products, we can find the appropriate and certified product for our clients.

The features of Red Hat Enterprise Linux (RHEL) I appreciate most are centralized account management and SSO. The integration of SSO features, particularly with Azure Active Directory, benefits our organization greatly because it is very easy to grant appropriate access to the operating system.Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risk.

I don't believe there are any additional features that should be included in the next release.

I have been using Red Hat Enterprise Linux (RHEL) for more than ten years.

What works well for me is that it is pretty stable over the years, and I don't face many challenges with it.I have not experienced any downtime, crashes, or performance issues.

Red Hat Enterprise Linux (RHEL) scales well with the growing needs of my organization.

I evaluate customer service and technical support as brilliant.I regard that support as pretty good.

While I sometimes use other solutions, we are not limited to Red Hat Enterprise Linux (RHEL), and for some cases, we use Canonical products. A long time ago, we used SUSE, but not recently.

I would describe my experience with deploying Red Hat Enterprise Linux (RHEL) as easy.Managing Red Hat Enterprise Linux (RHEL) systems from a central management console is a form of centralized management.I am satisfied with that centralized management console.

I have seen ROI with Red Hat Enterprise Linux (RHEL).

When selecting Red Hat Enterprise Linux (RHEL), the other solution I considered was Canonical, which is direct competition at the operating system level. However, Red Hat provides a more complete integration between the operating system and platforms.What stood out to me in my evaluation process was how easy it is to integrate Red Hat Enterprise Linux (RHEL) into the existing IT processes of our clients, which is the main driver for us as cost concerns are not my focus. Maintaining security patching and support over the long term is also crucial for enterprise clients.

I have expanded usage of Red Hat Enterprise Linux (RHEL) for myself and my clients.My advice for other organizations considering Red Hat Enterprise Linux (RHEL) is that if you are talking about long-term solutions, you need to choose a base infrastructure that is supportable for a long time.I would rate Red Hat Enterprise Linux (RHEL) overall as a nine out of ten.

Red Hat Enterprise Linux (RHEL) basically runs the bank's apps as my main use case.

I like the feature Satellite the most because it has services to manage my multiple Linux servers.

Satellite has no parallel in the Linux distro world, especially for an enterprise, enabling me to manage my servers, patch them, create content, get them binaries, updated security updates, and all that. It makes it easier for admins and reduces the need for a lot of manpower, especially with Ansible that enables me to do configuration management of 20,000 Linux servers.

Red Hat Enterprise Linux (RHEL) scales with the growing needs of my organization very well as we are expanding ourselves.

Red Hat Enterprise Linux (RHEL) has helped mitigate downtime and lower risk because the servers can run for more than 300 days of uptime. I do have to reboot them for patching, but otherwise, they are a very stable operating system that doesn't crash for no reason. If I experience kernel panics, it often involves EDRs or agents such as CrowdStrike, but otherwise, it's very stable with proactive features. We had issues with CrowdStrike; they identified the issue with their kernel drivers that used to crash my OS and provided a patch to address it, so they take care of us.

The implementation had challenges like whenever we bring out new products, there's always one issue: Red Hat Enterprise Linux (RHEL)'s documentation is not complete. I have to really have an enterprise account because I get access to their support, which sorts me out since every environment is unique. It's not a cookie cutter; I would deploy RHEL 8 in a way different compared to a retail store. So when it gets to those niche deployments, they don't have anything documented. I really have to get hold of the support, saying, "Hey, I'm trying to do this. It's not working," and then they will give me a solution, but I would expect that a document would have solved that issue without raising a ticket. That's my only complaint.

The area for improvement in Red Hat Enterprise Linux (RHEL) is documentation. I don't have any other suggestions. I think it's just the documentation that needs improvement. Otherwise, technically, I don't have anything to suggest.

I have been using Red Hat Enterprise Linux (RHEL) for ten years.

I have experienced downtime or security incidents as a result of the solution when proper practices are not followed, especially if I am using any third-party security. You have to manage kernel options; otherwise, the base OS itself is very stable.

Red Hat Enterprise Linux (RHEL) scales with the growing needs of my organization very well as we are expanding ourselves.

I would evaluate customer service and technical support based on my experience. I felt naive about being a small enterprise versus a big enterprise, but the response time of tickets is consistent. I haven't seen a difference; I thought I would have a slower response being on a small account, but the speed of our calls is the same.

I considered other solutions before choosing Red Hat Enterprise Linux (RHEL), but it was a default choice for us. I see that they have expanded; earlier, it was just a bare-metal OS and not an ecosystem, but now they are in OpenShift, providing Kubernetes and everything.

I wasn't using another solution to address my needs prior to adopting it.

The upgrade or migration is straightforward if I have applications that depend less on what the OS is, but in our case, it was not that simple. We had a business requirement, so we had to shut down the older one, provision a new one, and move everything.

I have seen ROI from using Red Hat Enterprise Linux (RHEL) in terms of uptime itself.

My experience with pricing, setup, and cost of the solution is that it's a service based on how many cores, not sockets.

My deployment model for Red Hat Enterprise Linux (RHEL) is on-premises, but I am just starting off with cloud.

For security requirements in the cloud, I don't do SELinux; I just depend on my ACLs because my servers are not internet-facing. We trust Red Hat Enterprise Linux (RHEL) with the binaries, with nothing on the base OS such as firewalls or SELinux.

I use AWS and Azure as my cloud providers.

I manage my Red Hat Enterprise Linux (RHEL) systems for security, updates, and patches with Red Hat Satellite, which makes it very easy.

I have been involved in upgrades from RHEL 6 to 7 and from 7 to 8.

My assessment of Red Hat Enterprise Linux (RHEL)'s FIPS and security compliance features is that it's the best in the industry. They have FIPS, which I think is more for federal clients, and although I haven't used it, I know they offer it by default on their Linux.

My upgrade and migration plans are to always try to stay on the current version all the time, unless there's a legacy application. Any apps I manage are always on the latest Red Hat release, and we keep migrating them as Red Hat provides the first-ever release out, which is a requirement for our Satellite to support the latest version.

The area for improvement in Red Hat Enterprise Linux (RHEL) is documentation.

I would assess the knowledge base offered by Red Hat Enterprise Linux (RHEL) as paywalled, so if you don't pay for it, you wouldn't be able to access their system. The KB is pretty good, but you need to have a Red Hat account.

My advice to a company considering this solution is to go for it. It is supported by enterprise support from Red Hat, which I don't think any other enterprise can offer. While I know Canonical does it for Ubuntu, SUSE is another good option; however, the adoption is not there, and you don't have a lot of sysadmins. Red Hat Enterprise Linux (RHEL) is a bible due to the abundance of resources in the market. I would rate this solution a 10.