Red Hat Enterprise Linux (RHEL) Reviews

We use Red Hat Enterprise Linux to provide a Platform as a Service for our customers in the cloud, upon which we have built additional software. This encompasses Red Hat and Synthos, including all Red Hat derivatives.

We also use it for our security-related applications primarily due to the robust enterprise support and comprehensive security features it offers.

Using Red Hat Enterprise Linux for containerized workloads has increased security, stability, and trust, ultimately simplifying our work.

Red Hat Enterprise Linux enhances the reliability and security of our hybrid cloud environment.

Red Hat Enterprise Linux performs well for our business critical applications.

We chose Red Hat Enterprise Linux for our environment due to its robust built-in security features, including proactive security fixes and an enterprise-class operating system with reliable support services that enhance security and reduce risk. Furthermore, the secure base OS Docker image strengthens our environment's overall security posture.

Red Hat Enterprise Linux helps reduce our total cost of ownership due to its security, stability, and enterprise support. The tightly integrated Red Hat portfolio simplifies working with their products and achieving the desired return on investment.

The most valuable aspects of Red Hat Enterprise Linux are the security and stability it provides.

I encountered an issue updating the time zone for one of my assigned countries due to a daylight-saving time change. Although we collaborated with Red Hat to build a package that addressed the issue, it wasn't delivered promptly, necessitating manual workarounds to resolve the problem.

I have been using Red Hat Enterprise Linux for almost 15 years.

Red Hat Enterprise Linux is exceptionally stable, minimizing the risk of outages or issues stemming from the operating system itself. This reliability allows it to run seamlessly in the background, freeing administrators from constantly addressing kernel bugs or faults in core system applications, ultimately saving significant time and manpower.

Red Hat Enterprise Linux offers flexibility to scale as required.

My experiences with Red Hat technical support have been mostly positive, though I've encountered some issues occasionally.

Positive

Red Hat Enterprise Linux is suitably priced with various support tiers to match organizational needs and environments.

I would rate Red Hat Enterprise Linux nine out of ten.

When considering a Linux operating system, the choice depends on the intended use. For enterprise environments requiring dedicated support, Red Hat Enterprise Linux is recommended. Smaller projects or testing environments may start with a similar option and transition to Red Hat as the business grows.

We have almost thirteen servers. There are SaaS applications installed on this server. We leverage Java and the functionality during installation. We install it on the platform and configure it there. Some are custom applications. Our database is also in the Red Hat Linux environment. 

The solution offers users easy access. It's very simple to have and use, from an admin perspective. 

The offering provides me with all I need to serve the operation in terms of usage and capabilities. 

The general user commands are good. They are helpful for starting and stopping applications and restarting and editing files. The maintenance of user-level processes is easy. 

We're not using it in a graphical environment, we're only using command line mode. There may be a lot of features, however, I don't use everything since I don't need to. 

There are millions of commands you can use, although we use only five or ten.

Likely the solution has helped our organization save on costs. I'm not sure by how much, as I don't have visibility into that aspect.

It's very easy to use across physical, virtual, and cloud infrastructure. Specifically, on the cloud side, I have noted it's quite easy. Also, on a virtual machine, you can create a cloud version of your infrastructure in a minute. 

For my work, the solution is not missing any features. We;re only using the command line and that is enough for us. 

Maybe they need to make it easier to apply patches from different resources. That said, at my level of usage, I never have to apply patches. 

I've used the solution for almost ten years. 

It's a stable product.

While I'm maintaining 30 servers, there are hundreds of servers in use. 

The scalability is good. We are able to increase capacity and functionality based on our demands. 

I'm not sure if the company has plans to increase usage in the future.

I don't directly deal with technical support. I might send a ticket to my side, and if they have to, they would be the ones to reach out to Red Hat. 

We used Oracle Linux before we moved over to Red Hat Linux. We likely switched due to costs and licensing. We also use Windows extensively. Since we used the same architecture, we didn't need to use any third-party applications.

As an admin, I was not involved in the setup process. 

If there is any maintenance needed, we get support from the Red Hat team.  If anything comes up on the operating side, our team will take care of it. 

I'm only using this solution as an admin and, therefore, have no visibility on costs. 

We did not evaluate other options before choosing this solution.

I'm an end-user of the solution. I had admin-level access to the product.

Red Hat Enterprise Linux does not enable us to achieve security standard certification.

I'd rate the solution ten out of ten. 

My primary use case is for web applications and database applications. I've come across quite a few use cases at different companies.

The most valuable feature is the package management. It helps a lot. I also like the support. 

Red Hat is a Linux-supportive and well-managed offering. It helps a lot in terms of when we're working in production, it gives us the confidence that our packages are legitimate and genuine and we always have support available. It helps a lot. Red Hat Enterprise Linux gives peace of mind compared to other unsupported Linux distributions. 

I also like Red Hat Satellite. 

I haven't used Insights yet but it seems interesting. 

The ability to patch Red Hat Enterprise Linux through Satellite is a huge contributor to mitigating all of the compliance requirements.

Red Hat Enterprise Linux has absolutely affected our security's uptime. None of the other distributions are nearly close to what you can get with Red Hat Enterprise Linux. Red Hat Enterprise Linux is something that helps a lot in ensuring that your secure application is up all the time and that you're not getting hit by vulnerabilities. It is an easier way for you to mitigate vulnerabilities when they're around.

The knowledge base is very useful. The only thing is that you need to have an account to get access. In terms of the content, the relevance, and being able to use the knowledge base to address things I've needed to deal with, it's awesome. For example, I was trying to add proxy configuration to the package manager once and if it wasn't for the knowledge base, I wouldn't have been able to do it.

I like it the way it is. 

It's getting easier for the community to use it free of charge. If you have an account, you get to use it. It would be better if the community could use it on their own for lab projects.

I have been using Red Hat Enterprise Linux since 2011. It's been 12 years. 

On the few occasions I needed to reach out to support, I was very satisfied.  

Positive

I have used Linux distributions but when it comes to the work I'm doing at my company, we always use Red Hat Enterprise Linux. 

The biggest differences between Red Hat Enterprise Linux and the other OS' are the support, Satellite, Insights, and the fact that Ansible was acquired by Red Hat so you can use all its automation and toolings. The entire ecosystem works very well together.

Red Hat has not personally enabled me to achieve security standard certifications in the projects I've worked on but I could see how it would help. 

I would rate Red Hat Enterprise Linux a ten out of ten. I really like it. 

We do a lot of patching and upgrading with Ansible and we keep the host up to date all the time.

We use Red Hat Enterprise Linux to run our GS and PSP applications.

Red Hat Enterprise Linux helps us avoid cloud vendor lock-in.

Red Hat Enterprise Linux helped us save on costs. 

The support and the stability are Red Hat Enterprise Linux's most valuable areas.

Upgrading between versions needs to be easier. For example, if we have Red Hat Seven running now and a Java exploit is found on Red Hat Seven, we need to be able to upgrade to Red Hat Nine online without any downtime in the environment. This is because it is not possible to reinstall the environment from Red Hat Seven to Red Hat Nine in production without causing downtime to the applications. Red Hat needs to have tools that ensure that we can upgrade from Red Hat Seven to Nine online without any issues.

I have been using Red Hat Enterprise Linux for almost seven years.

Red Hat Enterprise Linux is extremely stable.

Red Hat Enterprise Linux is scalable. We have around 1,790 end users.

The technical support is quick to respond.

We previously used Proxmox and switched to Red Hat Enterprise Linux because of the price.

The initial setup is straightforward because it is well-documented. The deployment time depends on the application. A small application can take around 20 minutes.

The implementation was completed in-house.

The cost is based on each organization's budget and infrastructure.

I would rate Red Hat Enterprise Linux nine out of ten.

The ease of moving workloads between the cloud and our data center depends on the application architecture. If the application has a monolithic infrastructure, it may be easier to move to the cloud. However, if the application is already running mostly in the data center, it may be more difficult because we would need to recreate all of the infrastructure and topology from scratch. This is because there are so many parts to consider when migrating a microservices-based application to the cloud.

For someone who wants to use an open source Linux operating system, I would recommend Rocky Linux. However, they should be aware that open source solutions do not come with the same level of support as Red Hat Enterprise Linux.

Four network team members are required to maintain Red Hat Enterprise Linux.

The Red Hat knowledge base is good and well-documented.

Red Hat Enterprise Linux is the only Linux solution that is supported for enterprise-level organizations. I recommend this solution for large organizations that want professional support for their Linux systems.

As a whole, our organization is using it on Bare Metal on-prem and the private cloud, and then also in more than one public cloud environment. We probably have all three cloud providers. We definitely have Azure and Google Cloud. The environment that I support has about 40 apps in one cloud or another, but the organization as a whole definitely has hundreds of apps in Google Cloud or Azure. They're predominantly in Azure. The Google Cloud adoption is pretty recent compared to our Azure utilization.

I'm supporting a capital markets environment. A substantial portion of my environment is still Bare Metal at Colos. I'm sure on the application side, there's plenty of JBoss in our environment. There have been recent conversations around OpenShift on-prem that I'm working on, and our enterprise cloud teams are looking at or are using ARO in the cloud. In the next year, our use of the Ansible Platform will go from zero to full throttle as quickly as we can make that happen. We found the event-driven Ansible very interesting.

They've helped us work on employing technologies suitable to our various use cases. We're pretty slow adapters of containers, but that seems to be changing fairly quickly at the moment. That certainly gives us portability for workloads. They helped us with some aspects there, and they've helped us with a lot of automation conversation at the summit this week as well around Ansible.

When it comes to resilience in terms of disaster recovery, the operating system is robust. If it fails, it's probably an app issue. The majority of work in any of our DR scenarios is dependent on whether we have got cold standby or hot standby. If it's hot, the data replication is already there, and things are already spinning. Maybe it's on or you turn it on. Other times, you may have to start up something. Nearly all of those things are application architecture decisions as opposed to dependencies or things from an OS perspective, but in terms of the ecosystem for managing our Linux environment, using Satellite and so on has been very good.

I prefer it to Windows because of the level of configuration, level of control, and the ability to see the performance of processes on a given system. I prefer the control over logging and the ability that logging gives you to investigate a problem.

Its community is also valuable. It's open source, and Red Hat-supported streams are also valuable.

The level of communication we've got with them is fantastic. 

The integration with the apps and support could be better.

A colleague was talking about having some recommendations for the Ansible Cloud on the console and having some way of identifying your dev or prod path and whether you've got read or execute access to a playbook. There were different things like that, and they made a lot of sense, especially if you're in a dev or prod environment because mistakenly running something in prod would be a huge issue. There could be something that Red Hat configures, or there could be a text field where organizations can add labels to a part of the console to distinguish that for themselves. Those would be things that would be useful. I can't imagine it's hard to implement but being able to know which environment you're in matters a ton.

As a part of my professional career, I've been using it since 2004. I joined my current organization in 2018. It has been almost five years since I've been working with Red Hat Enterprise Linux in the security environment of our organization.

It's stable. We rarely have our systems crashing.

It's pretty easy and getting easier. It's not an OS issue. In terms of scalability, even while running our trading apps, we don't run into limitations related to the OS. Our limitations are more hardware-defined, and even then, we're running Red Hat Enterprise Linux on servers with eighty cores and almost a terabyte of RAM, and the OS doesn't have any issues.

Their knowledge base is great. There are lots of times when we don't even have to open a support case because we find what we're looking for.

I've spent a lot of time with the Red Hat account team over the past nine months. They've helped me understand products. They've helped develop the skills of my team. They've helped us with technology conversations with other parts of my organization. They've been hugely supportive of the technology conversation we're having with other parts of the bank.

They've been over and above the expectations in most cases. I'd rate them a ten out of ten. I don't know if it could be better. It has been extremely good. They've been extremely helpful in reaching out and figuring out what they can contribute. The account manager that they have working with us is a former colleague, so it's a really smart decision because we have a very good relationship with the guy. He knows our environment. It has been extremely positive.

It's a growing relationship with Red Hat. We have been using Red Hat Enterprise Linux for a very long time, and I don't know if we can even compare it to the other OS vendors, but having the account team working with us with that level of experience with our environment helps them work with us. It helps us accomplish what we're trying to do. It has been a very good partnership.

Positive

We get our licenses directly through Red Hat.

We haven't used the image builder tool or insights, but it's something that we might explore in the coming months. 

I'd rate it a ten out of ten. It's very customizable and very supportive. It never seems to crash. There could be better integration with apps, but from an OS perspective, it's excellent.

Red Hat Enterprise Linux specifically was a hard requirement for certain software that we wanted to utilize. In fact, purchasing Red Hat’s enterprise version was necessary to run AP. That was the primary objective.

Apart from that, the robust networking capabilities offered by Red Hat Enterprise Linux were highly valuable. They have numerous partnerships and dedicated efforts in low-latency technologies, which are particularly beneficial for trading firms. They possess extensive expertise in external tuning and similar aspects.

Overall, the reliability stands out the most for me. While the package selection might be somewhat restricted, it is highly integrated and cohesive.

I'm really excited about some of the developments happening in the workstations and the Fedora Silverblue space. There are advancements like rpm-ostree and the OCI container format, which enable deploying RHEL in new ways.

As we have numerous developer workstations, being able to deploy them in an image-based format is highly desirable. This would allow us to use the "toolbox" concept, where developers can choose any desired operating system within the toolbox. Some of our developers also work with Ubuntu and Oracle Linux. Having a consistent developer platform with full pseudo permissions and zero permissions within that container or toolbox would be beneficial.

Additionally, having an image that includes all the necessary software and provisioning it so that subsequent updates provide the updated image, would significantly enhance the developer experience. It would be great if teams could make modifications and changes to the image, like rebasing. I think it would be an awesome feature.

Let me provide an example of why this would be valuable for Red Hat Enterprise Linux Workstation. We recently switched from one security software application to another similar application on our workstations. We had to manually remove the unwanted software and install the new one. It was manageable for servers or edge devices, but for remote devices that are not always on the network or VPN, it became a cumbersome task to reach out to each device and remove and install the software. If we could update an image with the old software removed and the new software installed, and then allow users to update their image, it would simplify the process for everyone. Currently, it's possible with Red Hat Enterprise Linux for Edge, but it would be fantastic if this capability could be extended to Red Hat Enterprise Linux Workstation as well. That's what would be really cool.

The company has been using Red Hat Enterprise Linux for a significant period of time. As for myself, it's been around five years or so. I have also contributed to GNOME. About ten years ago, I was one of 12 individuals who wrote documentation for GNOME 3.

I don't think we are leveraging Red Hat Enterprise Linux on the cloud. Since we are primarily involved in trading, our infrastructure is predominantly on-premises, accounting for about 80%. We have our own data centers. While we do have some cloud workloads and our cloud presence is growing, it isn't a major focus in my role. I serve as the lead engineer for 700 developer workstations that run Linux. For parts that use Red Hat Enterprise Linux on the cloud, we are split between different cloud providers, AWS, Azure, and Google Cloud.

For the most part, we are using Red Hat Enterprise Linux 8, which we support alongside Ceph and a bit of AAP. Apart from that, there is still a significant amount of CentOS 7 in use as people are gradually transitioning away from it.

The stability is good. I would rate it a nine out of ten.

The scalability is impressive. I would rate it a nine out of ten.

The customer service and support were pretty good. We encountered an issue, and we involved some people for assistance. In retrospect, we should have engaged higher-level support sooner for that specific issue. Support can be challenging when you're dealing with Linux problems, especially in our environment where we have a lot of skilled engineers; it feels like we're already operating beyond the normal troubleshooting space. So having access to escalated help when we need it is valuable. The support fixed our problem.

Positive

The initial setup was complex because we were using a newer version of Red Hat Enterprise Linux for the server team's workloads. Normally, we go with Red Hat Enterprise Linux for hardware, but this time we got a better deal from a different vendor whose IPMI Redfish interface wasn't as advanced as Red Hat Enterprise Linux's. This caused some issues specifically related to deploying the newer version. However, once we managed to overcome most of those challenges, the use of Ansible for OS deployment became more straightforward.

For the OS component, we worked directly with Red Hat. However, we utilized a company called Bits, based in Elk Grove, Illinois, to handle the hardware provisioning and setup.

We've seen an ROI. For instance, we were able to run a storage workload on one cluster that had an immense capacity. I calculated it to be the equivalent of either 16,000 iPads or 64,000 iPads. It was a significant amount. This capability is beneficial for us as we deal with a lot of trading data. We can perform analytics and machine learning workloads on it, which aids in compliance and enables traders to make more informed trades. It's a win-win situation.

The compliance aspect ensures that we stay out of trouble, and the machine learning capabilities help traders make better trades, which ultimately contributes to our success. I'm glad that they make money. It's wonderful.

Red Hat is making efforts to simplify the SKU system, which is a positive development. It's beneficial to have the flexibility to allocate a certain budget to explore different licenses within the Red Hat ecosystem. We can try out products and decide if they meet our needs. If they don't, we can decommission the corresponding SKU. I have noticed that we have some Red Hat entitlements that we are not currently utilizing, so having granularity in the SKU structure would be an advantage.

For our specific use cases, certain products like SAP, AAP, and OpenShift require Red Hat Enterprise Linux. That played a significant role in our decision.

Red Hat Enterprise Linux’s built-in security features, in terms of simplifying risk reduction and maintaining compliance, are an area where I've observed some of the developments with Satellite and Red Hat Insights. But since we have different operating systems, such as Windows, Mac, Linux, and a mix of server and desktop environments, I'm not sure if Satellite or Insights can integrate seamlessly with all these platforms. Currently, we use a different product to assess our CVE vulnerabilities across hosts, including phones and other devices. I do find the discussions about software supply chain security intriguing. Focusing on that aspect seems really promising.

The portability of applications and containers, specifically for those already built on Red Hat Enterprise Linux, seems pretty good. Red Hat offers UBI images that are freely available without the need for licensing. Red Hat Enterprise Linux and container platforms provide a solid setup for portability.

Overall, I would rate the solution a ten out of ten.

We use Red Hat Ansible Automation Platform. We are using version 8.4, but we started with 8.3.

The solution’s stability is its most valuable feature. It has only been two years since I first started using the product. So far, I have seen a subtle comparison of the solution’s stability to other operating systems.

It is challenging to use the knowledge base and the deployment documentation. Some of it is all over the place, and it's challenging to piece them together.

It has been two years since we put in the first footprint of Red Hat Enterprise Linux in our organization.

We have about 30 to 40 servers.

The support team is pretty good. Whenever I send support requests and ask questions, the team is knowledgeable enough to get me the necessary answers. Sometimes there are delays in the response. However, it has been a positive experience for me.

Positive

I was the main engineer during the initial deployment of the product. The initial setup was straightforward. Whatever was in the documentation was exactly what was meant to be done.

We did not struggle with the documentation because I have been an engineer for years. Someone who is just getting started might have a different perspective on the ease of setup.

We purchased the solution from a third-party vendor.

I use Ansible Builder to build my containers. However, I do not use Red Hat Enterprise Linux’s image builder tool.

We do not use Red Hat Insights yet, but we're planning to use it in the near future. As soon as we get more servers in our environment, our firm’s directors might decide to start using Red Hat Insights. Right now, we are just using Automation Analytics. The solution’s resiliency is pretty solid.

We implemented the solution because we wanted automation. We cannot install Ansible Automation Platform in operating systems other than Red Hat Enterprise Linux.

Overall, I rate the product an eight out of ten.

We're the largest financial institution in Africa, and we use various operating systems and technologies to achieve typical financial service goals. In the past, we were an ION-centric shop. However, in the past decade, we've been increasingly leveraging Linux's agility compared to traditional Unix operating systems. 

Generally, we deploy by cloud, but we use RHEL on-premise in our data centers and prefer SaaS for infrastructure as a service. Our primary cloud providers are AWS and Azure, and we also use smaller third parties for niche environments.

RHEL is spread across virtually all elements of the institution, including headquarters and various locations on multiple continents. In my environment, it is part of a global trading settlement system. 

The rollout for this particular solution was probably about 250 users of the application running on the initial RHEL. We're a global bank, so the user base is much larger worldwide. Users include business and feature analysts, engineers, and project managers. Our infrastructure engineers were the ones pushing for a switch to RHEL, followed immediately by application engineers.

RHEL enabled us to move away from reliance on ION. We're free to choose the best-of-breed solution at any given time while keeping the cloud-agnostic infrastructure at the center of our deployments.

Our operational expenditures decreased, and RHEL made our teams much more flexible. With RHEL, we can have multiple copies of an OS without making annual plans to license and acquire.

The benefits were instant from my team's perspective. For example, we were immediately more flexible and able to scale rapidly. However, if you're looking at it from an executive point of view, the time to value depends mainly on the product and the scale of the endeavor. It might take a few years to reap a return. Ultimately, you will see the financial benefit, but that's somewhat difficult to quantify in the short term. 

I don't think that it's enabled us to centralize development, but it has perhaps increased the breadth of development possible on our applications. In that sense, more development can be centralized on the operating system, but that's more of a byproduct.

We outsource cyber security to other teams, so I can't comment in-depth on RHEL's security features, but I can say it enabled us to understand our security posture more efficiently. This wasn't always possible using an AIX or Solaris in a more centralized fashion. The feature set is maybe not as important as having a single pane of glass and a single configuration to apply across our systems and infrastructure.

RHEL made life a lot easier in terms of compliance because you can more accurately gauge yourself against industry benchmarks with the tools provided and identify your shortcomings. You can interrogate what you've done through research from multiple parties rather than just a single source of truth, which may not be true.

You can compile and run applications on any operating system, but RHEL's advantage is flexibility. It is more supported and supportable in the enterprise sense than Ubuntu or perhaps a smaller distro, but it's also flexible enough to easily transport from platform to platform: ISA to ISA,  production to development, and vice versa. That led me to embrace the switch to RHEL from other operating system variants.

RHEL offers more portability than any other OS flavor apart from perhaps Ubuntu Linux. As a large bank, we run on IBM's architecture. We run Power, Spark, and Oracle x86 across multiple environments. It lets us choose the right environment for the application, which is essential from an operational efficiency perspective. These days, we're all trying to cut heavy infrastructure and move to lightweight agile infrastructure. There isn't a better option in the production world than Red Hat.

There needs to be a broader understanding of the RHEL suite's nuances like how the versioning works and implementing it on various kinds of infrastructure in use across the development landscape. There needs to be more training and education. It's difficult when you have a roadmap to deal with, but it is possible. 

Large application vendors may not have certified RHEL, or they have certified an older version. Most of the large application vendors are unfamiliar with the versioning that RHEL introduced, which I strongly support. They will support a given sub-version up to a point, not realizing that the sub-versions are essentially additive. 

This can be a real frustration when you try to deploy modern infrastructure. It allows tremendous flexibility because we can try things out across the cloud, virtual, and physical, but that's not always where the issue is. It's a matter of educating the engineers and developers on our side or enterprise vendors on the other. 

The licensing could also be simplified. While it makes sense from a theoretical perspective, it's a challenge to explain to the procurement team. Those with some technical expertise can understand how our licensing model works. However, it's still tricky because Red Hat is so different from traditional operating systems. It's another barrier when I'm trying to deploy it in an enterprise environment.

In terms of feature requests, I would point out that our company tends not to operate on the bleeding edge for obvious reasons. We look at what has already been released to define our roadmaps. There's nothing in particular that I would say needs to be included. However, I would like to see Arm playing a more prominent role in the cloud infrastructure and enterprise physical data center spaces. Red Hat supports this, but I haven't seen a clear roadmap for how that support should evolve within the Red Hat operating system environment. 

I have used Red Hat Enterprise Linux for more than 10 years.

RHEL's stability is good. 

RHEL is highly scalable and we plan to increase usage. 

I wouldn't rate Red Hat support as less than eight out of ten because I can't think of anything negative to say. I can't think of a time when I haven't been able to get it. Also, because RHEL is global and Linux is open-source, you can typically get the support that you need through research forums and the knowledge base. It's seldom necessary to involve third-tier support within RHEL.

Positive

We still use other operating systems. We've used just about every solution you could name in conjunction with RHEL. We also deploy Ubuntu. In some cases, our application vendor requires us to stick with a given solution. Sometimes it's AIX or Solaris, but mostly we can override that and move to RHEL. Red Hat is now standard for most future enterprise deployments, and we run RHEL on mainframes too, but in a very limited fashion.

The setup was complicated only because the applications we were trying to run were not certified to run on RHEL. It was version 6.8, so we worked with major global vendors to add the certification for the versions we were trying to run. That was the complexity. The application always worked beautifully, and the performance was excellent. It wasn't a question of getting the development to work; obtaining an issue of getting certification for the platform, which is required for any financial institution.

From a development perspective, we proved the concept and ran a mirror of production and development to demonstrate the improvements in OpEx and performance. Getting it up and running in parallel was the key to getting it all to work correctly, and it was instrumental in convincing any dissenting voices of the value. 

The deployment took less than three months, but the certification took nine.
The team supporting the first application numbered around 50, and the small group involved in the initial switch had about eight people.

The entire application is run exclusively on RHEL, so the whole operation team is probably around 40 or 50 people. It's worth adding that our overall group runs about 20,000 servers, so it's challenging to say overall what the RHEL footprint is.

After deployment, RHEL requires maintenance to keep the solution up to date. Security requirements tend to be more prohibitive or less encouraging of change. It's a question of changing mindsets and explaining that something doesn't have to be legacy-tested to update. The security benefits of updating are more critical than testing to ensure the update hasn't introduced more flaws.

I don't have the data, but we have significantly reduced operational expenditures since switching to RHEL. It was a reduction of more than 10 percent. 

The licensing is tricky to understand. Enterprises want to be beyond reproach when it comes to licensing. We would rather over-license than under-license. However, that can be complicated with a high-performance development team who may need multiple operating system instances or want to experiment with spinning up many machines to see if something works or sticks. 

We don't necessarily need support for those. Our procurement team is confused if we need a license for an instance that was only up for 15 minutes on Thursday. We need to make sure that we always have sufficient licenses. That misunderstanding of how cloud development works can sometimes slow down development. It inhibits the growth and success of Red Hat Enterprise Linux globally. So more education around that would be beneficial or at least will provide more clarity.

RHEL's total cost of ownership is difficult to quantify, but it's almost irrelevant. In cases where you don't care, you can always use an open-source OS. In other cases, you need the support and certification that comes with something like RHEL. I do not believe RHEL has any competitors in our use case.

I rate Red Hat Enterprise Linux nine out of ten. My advice to prospective users is to try RHEL out and see if your application works. In the long run, the benefits will outweigh the time and effort spent migrating. The important thing is to ensure you run programs in parallel so you can accurately evaluate the benefits and make a case for switching.