Red Hat Enterprise Linux (RHEL) Reviews

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.

Our business is primarily focused on software development. We are doing development and deployment using containers. We are mainly using Docker, but we might also adopt Podman later.

Our business logic is mainly for our own software development. We mainly have Java applications, Java containers, Tomcat, and Java frameworks. These solutions cater primarily to our business-level operations.

We are using Red Hat Enterprise Linux on-premises.

Red Hat Enterprise Linux gives us a standardized way of handling various tasks. Everything is the same in our environment.

It gives a standard procedure to do everything. It also gives standard APIs and a stable environment.

It works very well for our business-critical applications because of its stability and support. We have some kind of support in terms of the life cycle of the operating system.

Its long lifecycles, updates, support, and documentation help with business continuity and compliance. With reference architectures, we can straightaway get working solutions.

We can rely on security features like SELinux and run several workloads for WordPress and so on. We can rely on Red Hat.

We have used Red Hat Insights for certain things, and it has been helpful.

Stability, support, and life cycle management are valuable. We get fixes quickly. We can rely on them for features and so on. We can rely on their support. In the case of an issue, we can get somebody on the phone.

Red Hat could offer a containerized version of the operating system, potentially moving towards a more containerized ecosystem. 

More flexible tools for dealing with complex things like SELinux would also be beneficial. Its built-in security features are good, but they are quite complex to manage at an atomic level.

I have been using Red Hat Enterprise Linux for 25 years. We are mainly using Red Hat Enterprise Linux 9, but we also have Red Hat Enterprise Linux 7 and 8.

Red Hat Enterprise Linux is very stable. However, sometimes, there might be some load balancing issues leading to performance issues, so we have to figure out all those. Usually, Red Hat tools are helpful for that.

With automation, we have been able to handle scaling efficiently. We are using an internal cloud, which suits our needs without relying on OpenShift or VMware.

The support from Red Hat is very good. We have collaborated with Red Hat remotely and have been satisfied with the assistance provided for our customers' cases.

Positive

The pricing is suitable for midsize to large companies, though small enterprises might struggle. It is comparable to Windows licensing.

I would advise considering the lifecycle and support that Red Hat offers. They provide long-term support and have best practices for addressing vulnerabilities and attack vectors.

I would rate Red Hat Enterprise Linux an eight out of ten.

I use the solution in my company mainly for the operation system of the core business applications.

My company has experienced benefits from the use of the product, especially considering the agility that the tool offers in terms of the time to market in different areas of business and because of its compatibility with most of the applications in the market.

The most valuable features of the solution are the stability and scalability.

I run Red Hat Enterprise Linux (RHEL) on a hybrid cloud deployment, and it has impacted our company's operations, but I would say that it has been quite simple to implement, especially considering the security, which has been a considerable piece of the infrastructure.

Red Hat Enterprise Linux (RHEL) has helped centralize development in our company. The applications run with Red Hat Enterprise Linux (RHEL), and it became the standard for the operating system for the applications.

My company uses Red Hat Enterprise Linux (RHEL) for containerization projects with OpenShift. This use of Red Hat Enterprise Linux (RHEL) has had an important impact on containerization, as it is a simple process. Owing to the simplicity, we always involve the solution's experts and get faster solutions.

The built-in features of Red Hat Enterprise Linux (RHEL) for risk reduction, business continuity, and maintaining compliance are very important because our company is always aware of all these security issues that constantly happen.

Though the product has many features, the tool's virtualization area has certain shortcomings that require improvement. The product should also offer more containers and probably some financial services.

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

It is a very stable solution.

It is a quite easily scalable solution.

The technical support for the solution is very good. I rate the technical support a nine out of ten.

Positive

Before Red Hat Enterprise Linux (RHEL), my company used to use Windows. My company started to use Red Hat Enterprise Linux (RHEL) after we found that it offers more stability, sophistication, and security and serves as a standard for many products.

The product's initial deployment phase was easy and quick.

My company did follow some strategy to deploy the product, and we also had the support from the vendor.

The solution is deployed on the cloud and on-premises models.

My company sought the help of a system integrator during the implementation phase of the solution.

In terms of ROI, I see that the tool offers stability, performance, agility, and resilience.

If I describe my experience with the product's price, I would say that we have to live with it for now.

My company evaluated other Linux products, such as SUSE Linux Enterprise Server (SLES), against Red Hat Enterprise Linux (RHEL).

I would recommend Red Hat Enterprise Linux (RHEL) to a colleague who is looking at open-source cloud-based operating systems for Linux since it is a tool with more market experience and offers more documentation and support from the vendor, which is not easy to acquire when it comes to open-source software.

Red Hat's portfolio has affected the total cost of ownership across our enterprise landscape by around 10 to 20 percent.

My company has the product in two data centers, but the production happens only in one. Mostly, my company uses the cloud services offered by Azure.

I rate the tool a nine or ten out of ten.

I utilize Ansible to harden Red Hat devices across a multitude of disconnected environments.

One benefit of using Red Hat Enterprise Linux is that a lot of backend applications run natively on Red Hat Enterprise Linux as opposed to a Windows-based option. We are a partner with Red Hat. It essentially allows us to do a lot of our infrastructure stand-up and development.

It has enabled our team to centralize development. We have been able to centralize our automation, playbooks, and different collections we use within Ansible to create a centralized code base. We can use that to configure different types of systems with different requirements from different customers. Having a common platform across the entire enterprise has been very helpful.

We are using Red Hat Enterprise Linux very limitedly for containerization projects. It makes things very seamless. If we get a new developer, we can set up a brand new instance of a container for a dev environment or a test environment. It allows different developers to always have the same starting points with containers.

In terms of security features for risk reduction, there are SELinux and FIPS. Also, when you build a Red Hat Enterprise Linux machine, you can stick it right out of the box. It is very helpful. It is very good, especially for programmers and users who do not know anything about cybersecurity. It takes you 85% to 90% of the way. It has been very helpful and good.

The right commonality across the business or enterprise is always very hard to do, especially when different networks and different customers have different requirements. Being able to at least have continuity between those different environments has been helpful. If you have a system admin at a location and you put him or her at a different location, they at least can expect the same type of infrastructure.

When it comes to compliance, it takes you 85% to 90% of the way there. Different networks require different things. Some cannot implement specific standards for whatever reasons, but being able to utilize and leverage Red Hat Ansible to configure that and make sure those changes are made across the entire network has been very helpful.

Portability depends on the circumstances. Some things are more portable than others, such as containers. We utilize Ansible Core very extensively, but other things, such as AAP, are not necessarily as portable because some of our smaller environments do not have the bandwidth or the actual resources to support a big product like that.

In Red Hat Enterprise Linux, I am a big fan of the command line. I like the data manipulation and different commands that we can use. I use Ansible extensively to configure systems.

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

It is very stable.

It is easily scalable with the solutions and the options they have.

Their support is very good. They are very helpful. Some of them are more experienced in handling the niche problems that we have.

I would rate their customer support a nine out of ten because there is always room for improvement, but it has always been very good.

Positive

We have used Ubuntu and other Linux operating systems in the past. However, since I have been with the company, we have used Red Hat Enterprise Linux almost exclusively.

The deployment model depends on the environment. Some are using VMs. Some use containers, and some use bare-metal installations. It depends on what a particular program needs. I support small environments that are on-prem.

It is fairly straightforward to deploy different Red Hat boxes. I was just helping out a sysadmin the other day who had not done it before. It was super straightforward and super easy to deploy.

We deploy it on our own. 

The return on investment for us and our team is specifically automation. We are able to invest time on the frontend to create different automation playbooks, and we are able to push that out to not only a singular network but also to multiple networks and multiple different configurations. It takes a little bit in the beginning, but there are huge time savings in the end.

If a security colleague is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would be interested to understand what that colleague's objectives are and why they would consider something other than Red Hat Enterprise Linux. If it is something that fits their particular use case more, they can obviously go with that. Red Hat Enterprise Linux is a standard solution for Linux. If any colleague wants to go for another solution, I have to understand why. I would have to understand what Red Hat Enterprise Linux is not able to provide. However, this has not happened to me.

I would rate Red Hat Enterprise Linux a full ten out of ten.

We primarily use it for enterprise software, databases, and some custom applications.

We have a stable base to deploy applications. We need a minimal amount of effort to troubleshoot problems with the applications that are related to the OS.

We are using Red Hat Enterprise Linux in the cloud, in the on-prem data center, and at the edge. We are also using Red Hat Enterprise Linux in a hybrid cloud environment. It has had a positive impact. It is straightforward to deploy. There was no bottleneck.

Red Hat Enterprise Linux has enabled us to centralize development. The stable base that each developer can rely on is great. The consistent ecosystem of the repository makes it easy to rely on.

We use Red Hat Enterprise Linux for containerization projects. Red Hat Enterprise Linux is quick to containerize, so when it started becoming mainstream, it was easier for us to sell to upper management to start doing more containerization.

There has been a positive impact in terms of the portability of applications and containers built on Red Hat Enterprise Linux for keeping our organization agile. It is very portable. I do not have any issues with different ecosystems in relation to how Red Hat Enterprise Linux runs containers.

Our cost of ownership is not high. They are not very expensive. We are never surprised.

The repository ecosystem is valuable. 

I would probably focus more on a rolling release schedule. Instead of a long-term operating support of ten years, I would just have one release and keep rolling it.

In terms of security features, overall, it is lacking cohesion. There are a lot of different options, and it is hard to choose the ones that best fit our business needs without a lot of investigative work.

I have been using Red Hat Enterprise Linux for 11 years.

It is very stable.

It is scalable.

It takes a little bit to get to the true answer. I know there is a lot of triaging. I am sure we can improve on our end. When we open tickets, we can provide more information. There could be a way to get faster answers from Red Hat support, and we might not be providing the most upfront information needed for the ticket. I would rate their support a ten out of ten.

Positive

We were not using any other solution previously.

I know of only one other player, and that is Ubuntu. There is also OpenSUSE, but I have not yet seen that personally in my career.

We have cloud and on-prem deployments. We have the AWS cloud.

On AWS, we had an EC2 instance. I clicked, and it was online. For the initial deployment, we just used the Amazon Web UI, and now, we use Ansible for deployment.

We have seen an ROI. It is fairly easy to deploy. We do not have too many issues with setting up a new environment in relation to the operating system. The bottlenecks are more related to the hardware or even setting up the cloud.

When I came in, Red Hat Enterprise Linux was already being used. It has always been there.

We have not yet fully leveraged Red Hat Insights. We are working on that. It might help with cohesion and security.

I would rate Red Hat Enterprise Linux a ten out of ten. It is reliable for deploying applications. It has a lot of different features. I can find solutions to all my problems, and the industry support is there.

We use Red Hat Enterprise Linux in different application servers. 

The tool's most valuable feature is simplicity. There is value in having a fully CLI-based operating system instead of a GUI-based one. It is lightweight and can be leveraged without resource constraints. 

I want Red Hat Enterprise Linux to stick to the open-source routes. As a company, we experience challenges in managing the budget. 

I have been using the product for three years. 

From a licensing perspective, Red Hat Enterprise Linux is flexible. We leverage our licenses based on the VMware cluster. 

Accessing the knowledge base from the public perspective is challenging. You can get much more from the documentation if you are a supported organization. If Red Hat Enterprise Linux continues to keep the documentation open-source, it will benefit us. 

We leverage Ansible to help with the upgrades. It makes upgrades easier. We rely on a reseller for Ansible AWS upgrades. 

We are shifting our Red Hat Enterprise Linux servers from version 7 to version 8. 

I rate the product a seven out of ten. 

All our infrastructure uses Red Hat Enterprise Linux. Every service we run is all Red Hat Enterprise Linux. Even containerization is on it.

It has improved our organization. It has standardized processes. Everyone uses it. 

The upgrades are straightforward which helps when you want to move a major version of an upgrade. It's done in a standard way.

Everything we do is all Red Hat Enterprise Linux. Red Hat Enterprise Linux's security has been good because I have never seen any application going down due to security reasons. 

Red Hat Enterprise Linux enables us to achieve security standard certification. For example, we have a very tightly SCC-regulated company so there are many rules that we are to follow and we are able to achieve this using Red Hat Enterprise Linux.

I have been using it for six years. 

We are all on-prem, but we also have some footprints in AWS but those images are also on Red Hat Enterprise Linux.

Red Hat Enterprise Linux has supported our hybrid cloud strategy. We have a few things running on AWS. We have a few things on OpenShift. We are able to get all the basic images. It is easy to start and deploy anywhere.

One thing I like is the updates because when we patch it and upgrade it, we save a lot of time doing those upgrades and migrations.

Moreover, upgrades or migration to Red Hat Enterprise Linux have been straightforward in some ways. For example, we are currently migrating to Red Hat Enterprise Linux 8 and we have all our servers running on RHEL 7. We have scripts that are very easy to migrate.

For our implementation strategy, we go environment by environment. We start with our development environment. Once we are done with it, we test it. We have some automation test suites, test them, and we go to the upper environment.  

We worked directly with Red Hat for the deployment. We are already working on Red Hat Enterprise Linux 8 migration. Every year, whenever there is a major version release, we migrate to the major version.  

We see a return on investment in terms of saving time. One thing I like is the updates because when we patch it and upgrade it, we save a lot of time doing those upgrades and migrations.

Overall, I would rate the solution an eight out of ten. 

We use Red Hat Enterprise Linux for our on-prem VM infrastructure. Recently, we got the OpenShift platform to help with containerization on-prem.

Moreover, containerization is one way we're trying to get rid of any legacy. We don't patch. We try to have a fresh build with the newer version of the patch. We try to use those Red Glue deployment strategies and remove whatever we find in misconfiguration or vulnerability instances rather than fixing them. We redeploy it.

In terms of improvement within the Linux environment, especially for a non-IT company like ours, where we have a limited number of Linux administrators and specialists in Linux hardening and security, Red Hat Enterprise Linux plays a significant role. 

It eases the burden by restricting the use of open-source Linux and preventing the development community from obtaining their own images. This is crucial for maintaining a secure supply chain and ensuring the lockdown of live Linux packages.

However, when it comes to security compliance, I have not been exposed to the Red Hat Enterprise Linux security; we got the advanced cluster security from OpenShift, which has some vulnerability tracking within the cluster. Within Red Hat Enterprise Linux, I have not experienced the security console yet.

Red Hat Enterprise Linux has affected our systems and our security. It helps us achieve security standards. It's one of the hardening requirements so, it helps with that compliance requirement.

With standardization across the environment, we don't have to generate multiple artifacts for compliance, and having a single Linux platform management like Red Hat Enterprise Linux helps to satisfy auditors a little faster.

From a security perspective, the overall hardening of Red Hat Enterprise Linux is good. It has been effective in enhancing security.

Image management and hardening are essential, so we don't have to procure open-source Linux images that developers can get themselves. It adds a layer of security with signed images.

The knowledge base is pretty good.

From a cloud perspective, I'm looking for more integrations with native cloud services. For example, the ability to use native Azure Key Vault instead of Ansible Key Vault or Red Hat Key Vault. 

Additionally, integrating image services from Red Hat into native image repositories such as Azure, Google, or third-party image repositories like JFrog is crucial. The key focus is on integration. 

Red Hat should not become Microsoft and lock down functionalities within Red Hat. 

We have been using Red Hat Enterprise Linux for two years.

We have premium support, so it is pretty good.

Positive

We are a mix of some other cloud virtualization technologies. The overall cloud information will define how we look down the road.

With Linux management, the pros are that it makes management a little easier. Overall, it is just a single view of the images we deploy in the organization. 

The cons are that the integrations are a little tricky sometimes, and then we have to make exceptions to our policies. Better integration, more native service using more credentialless authentication, and authorization like using service principles or managing these over-store credentials would make it better.

Currently, the emphasis is on on-premises solutions.

Overall, I would rate the solution a seven out of ten because it needs more integrations.