Red Hat Enterprise Linux (RHEL) Reviews

We have Ansible deployed on our Red Hat Enterprise Linux servers. We use it to manage the security of our fleet of Ubuntu virtual machines.

Red Hat Enterprise Linux is way ahead of Ubuntu in terms of security and compliance. It is mainly the ecosystem of data science tools that our developers want that pushes us in that direction. As a security engineer, I have a lot more peace at night knowing that my Red Hat servers are doing a good job keeping our Ansible infrastructure safe because that has fingers into everything we do. It is pretty critical.

Red Hat Enterprise Linux has not affected our system's uptime in any particularly noticeable way.

Red Hat Enterprise Linux has not enabled us to achieve security standards certification because we do not have any yet. We will have them hopefully in the future.

There are some nice integrations with scanning for vulnerabilities. That is the feature I have enjoyed the most because I am a security person, and that is my bread and butter.

Ansible has certainly been a game-changer. It is a lot easier to keep a whole bunch of virtual machines consistent with each other and make a change consistently across all of them. We use them for data science activities. Our data scientists are constantly trying out new packages and downloading new tools. We have to enable them to have root access on their machines but also need to ensure that they are not doing anything stupid at the same time. There are competitors to Ansible, but we are a big Python shop, so it is a very comfortable environment for us.

The only issue we have had with it is around the SELinux configuration because the way Ansible installs, it sticks the platform passwords in a flat file. We want that locked down more strongly than what is there currently with SELinux. 

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

I would rate their support an eight out of ten.

Positive

Primarily, we have used Ubuntu. We have had some of our use cases on CentOS, and then, of course, our workstations are all Windows, but I wish they were not.

We chose Ansible, and that chose Red Hat Enterprise Linux for us.

We use Red Hat Enterprise Linux in the cloud. We have Azure because it is the corporate standard. We do not have any concerns about using Red Hat Enterprise Linux in the cloud. Obviously, everything in the cloud is more exposed than everything on-prem, but it has got good, sensible, and secure defaults built in, so there are no concerns there.

In terms of Red Hat Enterprise Linux upgrades, when we upgraded Ansible this fall, that pushed us from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. It should be a little easier from now on. Now that we have made the big jump from the older Ansible to AAP, we will probably be upgrading the systems on a quarterly basis.

We probably have not yet seen an ROI. We purchased it a couple of years ago, but we have not had the time to put it to as much use as we wanted to put it to. The cost is low, so it would not take very long to reach a return on investment.

We have not made use of the Committed Spend.

For its use case, I would rate Red Hat Enterprise Linux a ten out of ten.

We use Red Hat Enterprise Linux due to its robust security features, which are essential for securing e-commerce transactions and monitoring our Linux servers. Additionally, its flexibility allows for deployment across a range of devices, including HPE and Dell.

Red Hat Enterprise Linux offers robust provisioning and patching management capabilities, ensuring efficient system administration and security.

I am delighted with Red Hat Insights and recommend this feature to others.

Since using Red Hat Enterprise Linux, I have found it to be very secure.

Red Hat Enterprise Linux has reduced our downtime by about 60 percent.

Red Hat Enterprise Linux aids in achieving security standard certifications by providing a secure foundation and tools for compliance with various security frameworks.

The most valuable aspects of Red Hat Enterprise Linux are its flexibility and security. It allows us to manage servers independently and ensures security for any device used.

The system roles feature is good.

While Red Hat Enterprise Linux offers robust security features, continuous improvement is crucial to ensure a secure environment and prevent potential losses.

I have been using Red Hat Enterprise Linux for about six years.

I rate the stability of Red Hat Enterprise Linux as seven point five because sometimes it takes time to reach support for assistance.

I rate the scalability of Red Hat Enterprise Linux as eight. It is satisfactory in terms of scalability.

The response time could be improved as sometimes it takes too long to reach out to them.

Positive

The complexity of deployment can vary based on familiarity with Red Hat Enterprise Linux. I found it to be complex.

Red Hat Enterprise Linux can be expensive, but its cost is not a deterrent for many organizations willing to invest in its stability, security, and support ecosystem.

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

We have 80 percent of our environment using Red Hat Enterprise Linux. A team of around 40 uses Red Hat Enterprise Linux to manage over 3,000 servers in a big environment.

We perform weekly maintenance on Red Hat Enterprise Linux.

We do updates, upgrades, and migrations on our Red Hat Enterprise Linux servers.

Based on my experience, I recommend Red Hat Enterprise Linux, particularly to those seeking a highly secure operating system.

The primary use case for Red Hat Enterprise Linux is automation. We have Ansible running on some Red Hat Enterprise Linux servers, and a lot of it is geared towards automation. We have the automation of processes like patching, upgrades, OS enhancements, or OS upgrades. Additionally, our stores run on Red Hat Enterprise Linux.

Red Hat Enterprise Linux is pretty secure, but we rely on our network products to handle a lot of our security. We have Cisco products. These servers that we are currently running are not necessarily tightened down on the ports, traffic, etc. We rely on Cisco firewalling to handle a lot of the traffic, load balancing, and so forth. I have not configured a lot of security per se right on the server itself at a kernel level.

I like the knowledge base. They have a pretty good knowledge base portal. On their website, they have a lot of great classes. I do appreciate doing that. I have taken several myself, so I am pretty impressed by that.

We use Ansible Playbooks for patching our devices, especially those that are out in the field. We are using Ansible Playbooks to handle patching. We are using the systemctl command that goes into the repos to grab whatever patches we need. So far, the management experience has been good.

I have used a lot of different Linux distributions, and one thing that I like about Red Hat Enterprise Linux is the support. The support from Red Hat is very good. They offer excellent customer and vendor support. 

The ease of training is great, and I appreciate products like Ansible Tower. 

Its interface is good. It is a very solid operating system.

Some of the documentation that I have run into or encountered appeared to be a bit outdated. That would be an area for improvement.

I have been using Red Hat Enterprise Linux since early 2000. It has been about 20 years.

Red Hat Enterprise Linux is very stable. I have not experienced any instances of crashing with the Red Hat servers that I have worked on.

Other than the issues with the legacy software or some of the IBM AS/400 that we tried to add to it, it has been pretty seamless. Building them out and migration to the data center or the VMware environment has been pretty seamless. 

Customer service is great. We use a support portal to open a ticket, and the response time is good. We usually get an email response or an update to the ticketing system, and then if necessary, we get a callback within four hours. The response time also depends on the priority. If we are looking at a massive data center outage, I am sure it is a priority one. Most of the tickets I submitted took one to four hours.

Positive

I have used SUSE in the past. They have a pretty good support system. They have got a good OS. I am not sure what the market share is for those guys, but they are pretty good.

Our environment is a combination of the cloud and on-premises, but we primarily use Red Hat Enterprise Linux on-prem. We have a few development test servers running on Azure. They are not used in production. They are just for testing.

I was involved with the migration from SUSE to Red Hat, but that was close to a decade ago.

From what I recall, the initial setup was not that difficult. We did have some engineers from Red Hat who came out to help us. It would have been more difficult if we did not have them there, but from my recollection, it was not very challenging or difficult. We were able to get that done pretty quickly. There were some issues with legacy software, but those applications were built on the Windows platform. They were a little bit of a mess. Other than that, it appeared to go pretty smoothly for us.

It does not require much maintenance. Other than patching and keeping up with bulletins as to what might be out there, there is not much. There is not a huge amount of maintenance. They run pretty solidly. The uptime is great. I do not have to restart a lot of these servers. I might have to restart a service here and there, but nothing that I can remember.

We had help from Red Hat engineers during the implementation.

Red Hat Enterprise Linux provides a much more secure and stable system than Windows infrastructure, and the support is also great. Of course, you pay for the support.

We were able to see its benefits after some time. Some of the returns are seen after a while, not immediately. Sometimes, migrations might be difficult to do if you are running legacy software.

I am not involved in the budgetary aspect, but from what I understand, the pricing is competitive, similar to what we paid for SUSE.

Having a solid foundation in Linux can be very helpful. Learn as much as possible. Automation has become a very important part of the industry now. Learning how to automate with Ansible, Kubernetes, Docker, and Python along with Red Hat Enterprise Linux should set you up for success.

We have not tried Red Hat Enterprise Linux Image Builder or System Roles. Image Builder sounds good, but I have not tried Image Builder. We build our images from vCenter. Image Builder would definitely be something to check out.

Using it in a hybrid environment is a very interesting concept, where we keep some of the hardware and applications on-prem and then maybe rely on Red Hat to handle some of the networking or other configurations externally. I would like to try that hybrid approach.

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

We have extensive contracts with Red Hat. We have it for the operating system. I manage the cloud deployment for GCP, and we have got Red Hat Satellite running in GCP. All of our VMs run on Red Hat Enterprise Linux in the cloud. On-prem, we are running Red Hat Enterprise Linux on our OpenShift cluster, and we have a supercomputer that has got 753 nodes with 50,000 cores running on Red Hat Enterprise Linux. We use a lot of the other products too.

There is consistency across the deployment. Generally, when you are looking to hire people, if you hire people who know Red Hat Enterprise Linux, they have a certain level of understanding that goes along with using the operating system.

It is easy to secure. It has a lot of built-in security features, and it is very stable, which is a big deal.

It makes it easier to have one team that deals with both on-prem and cloud because there is a uniform operating system and tooling. You do not have to have a set of admins where one knows one thing and the other one knows another.

Red Hat Enterprise Linux has enabled us to centralize development. We are using the same platform everywhere. It is the same tooling, and everyone is working in the same system.

We are using Red Hat Enterprise Linux for containerization projects. We are building out OpenShift on-prem right now on bare metal. We are running the hub cluster from GCP to spin up the bare metal cluster on-prem. We will hopefully be moving more and more things towards containerized workflows. We are running OpenShift, so it all runs on top of Red Hat Enterprise Linux.

For security, SELinux is built in. It is out of the box. It is built towards building a secure system. We are in the process of working on compliance and getting this 800-171 certified. That is in process. They have regular security updates and lots of tools for rolling out updates. In that sense, there is a continuous upgrade path that is well-worn and fairly easy to maintain.

In terms of portability of applications and containers built on Red Hat Enterprise Linux for keeping our organization agile, when it is in a container, it does not matter if you are running a UBI container or some other sort of container. If you have an environment that will run a container, you can throw a container in it, and it will run, so the portability does not belong to the OS at that point. It belongs to the containerization system.

It is consistent. It is geared toward security. I am used to it. I know only Red Hat Enterprise Linux. I do not know Ubuntu or any of the other flavors of Linux.

It is good. I do not have anything to improve for Red Hat Enterprise Linux, but CentOS could be open-source again.

I have been using Red Hat Enterprise Linux since 2014. I have been using Red Hat since 1.2. It was probably 1998.

It is very stable.

We have a cluster with 50,000 cores. It is pretty scalable.

Their customer service is good. We have a TAM. Our TAM is great. Without a TAM, it is hard to get new tickets through.

I have used many solutions. I have used many that predate Linux. For Linux, I have run Slackware, but that is just for fun. Professionally, it has all been Red Hat Enterprise Linux. 

Our deployment experience is good. For the things in the cloud, I use Satellite. I build images and deploy from images to the cloud. It is a mutable deployment chain rather than a standard upgrade path.

We deploy it in-house.

The vendor management takes care of that. 

We have an enterprise agreement. From our department's standpoint, everything gets rolled into the enterprise agreement, which is great because we never see it.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would say, "Why would you look at something other than that?" I have built things on Fedora and Red Hat Enterprise Linux. I was out of the industry for a while, and I came back, and I focused on Red Hat Enterprise Linux because it pays better. There are more standardized jobs in the area if you know Red Hat Enterprise Linux. The certification that you get from Red Hat means something quite specific.

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

We are deploying Red Hat Enterprise Linux as our primary Linux OS, and we are using Ansible for some automation initiatives. Our use cases are around centralization.

We have a supported product. We are at the beginning of building a relationship with Red Hat similar to the one we have with Microsoft, Cisco, and others. It is to standardize the quality, supported version, and company. I am leading this project, and I believe Red Hat is the one.

We have built a hybrid environment. Most of it is on-prem, but we also have Azure, so we have both cloud and on-prem environments. Red Hat Enterprise Linux is helpful for patch and vulnerability management. There have been a lot of security initiatives around Windows and tightening it up, but our Linux environment was not standardized. Red Hat Enterprise Linux standardizes it. With the combination of Insights, it aligns with Windows and other security initiatives.

Red Hat Enterprise Linux has not yet enabled us to centralize development. It is too early for that. I am not very familiar with OpenShift, but with OpenShift, Kubernetes containers, and some of those capabilities, DevOps will become more integrated with Red Hat and its products in the future.

Red Hat Enterprise Linux’s built-in security features seem very good when it comes to risk reduction, business continuity, and maintaining compliance. One thing that helps is the catalog of preexisting playbooks provided by Red Hat around security. It helps you ramp up on security. It aligns it with what an IT person on the Windows side already knows to look for, such as firewalls, setting up permissions, etc. They have playbooks for Active Directory integration, security initiatives, and limiting the firewall. Building out some of the playbooks that Red Hat has in those areas was helpful in getting a good security posture for those systems.

Ansible is going to make the portability of applications and containers happen for us. The OS is important, but our ability to use Ansible and deploy via a cloud or automate via a cloud or on-prem would accomplish that.

Red Hat Insights is valuable. There is patch and vulnerability management. It is similar to what you would see with SCCM. I have a single pane of glass interface. I can approve the patches and vulnerabilities, and hopefully, between Satellite and Ansible, we can automate that process.

I am looking for training. I am a Windows guy who accidentally became a Linux guy. You volunteer a few times, and you are the guy. Right now, I am looking for training and ramping up to be able to support their products, so professional services are key. There are things like Lightspeed with IBM Watson. I do not know YAML very well, so it is going to be integral for me to create playbooks at the very beginning and be able to use the AI tools. If I say, "How do I open a port on this Cisco router?", the AI tools are going to give me the YAML code. In spite of not being a Linux guy or a great coder, I can use those tools to ramp up very quickly. Making Lightspeed a part of Red Hat deployment initiatives tremendously helps with customers' success. It gives them that extra tool. Right now, it is being sold separately as a subscription. If they could integrate that capability, people would not have to go use ChatGPT and other tools. They could use that as a part of it. It would just align things with Red Hat, so one area they can improve on is the approach to customer success for new deployments.

Red Hat Insights are instrumental in identifying vulnerabilities. I am still learning, but my understanding is that it is not directly connected to your environment to deploy a patch or vulnerability fix. It is going to give a YAML playbook to do that. It does not actually execute it. On the Windows side, I have an approval process on the server where I can say, "Deploy this patch." I thought of Insights along the same lines where I can just approve things, and then based on some backend configuration, it will implement them using Ansible, Satellite, and on-premises Ansible. It seems disconnected right now. It might not be, but to me, there seems to be a gap there. I love Insights, and I want to fully automate that approval process. This could be a point for improvement if it does not already do that.

Another area of improvement is Red Hat expressing a return on investment better. I do not know if they have determined a lot of that. I have always assumed that I could go with an open-source OS in a less expensive manner than Windows or something else. My impression is that there would be less cost, but I do not know that for certain. Red Hat building out some of that ROI on different products would be beneficial to their sales effort.

We are a brand new customer.

It is more stable than the wild west environment that I have been in. There is standardization. It is stable by standardizing.

So far, its scalability has been good. Once I get a good image built, I will get some workflows built into Ansible. I will have that process all the way down to the help desk. We will be entering variables and kicking out systems all day.

We have been using it minimally. We have about 15% Linux environment with lots of flavors. Red Hat Enterprise Linux is what we are centralizing on from now on, so we are going to do a conversion of all those. We have a new standard going forward. We have about 15% Linux systems, which would amount to about 150 systems throughout North America. It is a small footprint.

I have not had to call them much, so I do not have a good handle on support from Red Hat. Everybody gets at least a C or a five, but I am optimistic. It is going to be good. I would give them at least a seven out of ten.

Neutral

Prior to Red Hat Enterprise Linux, it was CentOS and others. CentOS was free. It was whatever was available or the developers or applications guys were familiar with.

We switched to Red Hat Enterprise Linux for centralization, to be supported, and for patching and vulnerabilities.

Most of the things that I am deploying or replacing are on-prem and on Azure cloud. It is 50/50.

The deployment was very easy. They have a great and user-friendly installation process with 9.x and above. However, just being new to it and having a security hat on, I still struggle with what should and should not be installed on the base image. It is a learning curve for me, but using the interface has been great. I was able to join Active Directory and all those things.

CDW is handling our professional services and our training, which is a separate purchase. Its initial rollout is with CDW.

We have not yet seen an ROI.

It is expensive. Everything is. I was happy to get a three-year Red Hat Enterprise Linux contract for our initial rollout. 

It is less expensive than other solutions. It is a growing company.

It is called Microsoft ARC. It now facilitates patches for Linux, but it did not include certain things. For me, there was much more benefit outside of just patching by going with Red Hat Enterprise Linux and Ansible.

I am not yet certain about Red Hat Insights' vulnerability alerts and targeted guidance. We are at the beginning. We are just adding systems. I have not set those alerts up if they exist. I assume there are some. I am also going to evaluate how accurate the vulnerability and patching information is because we have other security products that are looking at the same things on the Windows side, and they have already identified many of the vulnerabilities. As a new customer, I want to make sure that if our other system says something is a vulnerability, Red Hat Insights also says that it is a vulnerability. I want to feel confident in the vulnerabilities that I am getting from Red Hat Insights. I want to make sure that other products are also scanning for the same thing. I suspect it is.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would recommend going for Red Hat Enterprise Linux. I cannot think of another OS that can match this.

I will start off with an optimistic ten, and I will rate Red Hat Enterprise Linux a ten out of ten.

The users utilize Red Hat Enterprise Linux for building, installing, and automating platforms. Additionally, we employ it as an installer for OpenShift clusters. Furthermore, there is a product called Red Hat High Availability Clustering and also JBoss. Occasionally, we also use it to build an Oracle RAC database.  

Red Hat Enterprise Linux simplifies risk reduction and compliance maintenance by utilizing bash scripts or Ansible to automate and streamline our tasks. Red Hat also offers a tool called Convert2RHEL, which simplifies the process of maintaining our products from Oracle, CentOS, and other vendors to Red Hat. This feature is truly remarkable.

The portability of applications and containers built on Red Hat Enterprise Linux is perfect for keeping our organization agile, especially when considering rootless containers or utilizing BotMan containers for enhanced security and performance. 

The Red Hat ecosystem enables the seamless integration of our products such as Ansible, Red Hat Virtualization, Red Hat Satellite, and OpenShift platform to fulfill tasks, thereby enhancing the efficiency of our organization.

Red Hat Enterprise Linux helps us reduce the time we spend on tedious tasks, and the large Red Hat community provides an easy way for us to maintain or fix errors and bugs. We were able to realize the benefits quickly.

Red Hat Enterprise Linux enables us to achieve security standard certification. I am a certified Red Hat System Administrator and Red Hat Engineer. The content of the certificate includes topics such as C Linux. This helps to make our organization more secure and stable and has an impact on our personnel sourcing.

Red Hat Enterprise Linux assists us in building with confidence and ensures availability across physical, virtual, and cloud infrastructure. While there is a higher level of risk associated with using a public cloud for any product, private or virtualized environments offer greater security.

Red Hat Insights helps us prevent emergencies caused by security issues, noncompliant settings, and unpatched systems by enabling us to be more proactive in detecting and avoiding errors before they occur.

Red Hat Insights provides us with vulnerability alerts and targeted guidance, especially when we register our host directly with Red Hat. It works perfectly because it utilizes machine learning, allowing us to monitor our logs and prevent unnecessary downtime.

Errata is the most valuable feature, which is supported by Red Hat. Errata is a list of corrected errors appended to a document in Red Hat, used for provisioning or batching our hosts. Moreover, its stability and security are noteworthy.

Ever since Red Hat acquired CentOS, the connection between the new CentOS Upstream and Red Hat Enterprise Linux has become unstable and requires improvement.

Red Hat Enterprise Linux's ability to run containerized applications is not optimized and has room for improvement.

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

Red Hat Enterprise Linux is extremely stable.

Red Hat Enterprise Linux can scale horizontally because it is in a virtualized environment. Vertical scaling depends on the deployment of the solution.

We have plans to increase our utilization of the solution.

The Red Hat technical support is excellent; critical issues are resolved promptly.

Positive

We also utilize other Linux operating systems depending on the use case. SUSE Linux Enterprise is more optimized for SAP products. When working with an Oracle database, it is preferable to use Oracle Linux.

The initial deployment was straightforward. The deployment time depends on two factors: the first factor is the infrastructure specs, and the second factor is what we are deploying with the operating system. For a minimal server, deployment takes five minutes. For a server with a graphical user interface, it can take up to 20 minutes.

The implementations are all completed in-house.

I give Red Hat Enterprise Linux a nine out of ten.

Red Hat Enterprise Linux is deployed in multiple environments, including pre-production, user acceptance testing, and system integration testing. Our Red Hat team, the development team, and another team utilize Red Hat Enterprise Linux within our organization.

Each processor architecture has a distinct version of the software.

The Red Hat exams are not solely based on security but also on performance. It is a challenging skill to grasp, but once learned, Red Hat Enterprise Linux will be flawless.

I highly recommend Red Hat Enterprise Linux, particularly for production environments, due to its stability and enhanced security features.

The most valuable lesson I have learned using Red Hat Enterprise Linux is that the entire Red Hat ecosystem is perfect. All the open-source projects can work together, especially for DevOps or when implementing valid automation or containerized applications. If we need to deploy a centralized application, we will use OpenShift. And if we want to perform tasks on OpenShift, we will use Ansible as an automation platform. If we want to upgrade or manage our environment hosts in batches, we will use Red Hat Satellite. If we have applications and want to create an environment for them, we will use Red Hat JBoss. If we want to run high-availability clusters or high-performance computing clusters, we will turn to Red Hat High Availability Clustering. Working within the Red Hat ecosystem is perfect.

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.

We use it for databases and applications. In the new model, we keep databases separate from applications. Currently, about 90% of our operations are running in Red Hat 8. Some systems are still on Red Hat 7, but those will be migrated off by the beginning of next year.

It's been great since we have it. It's been reliable and fast. We keep all the security agents, and we've been taken care of right away, and that's the improvement in our company. It's with the new RHEL. There's always something new, something good that works for us. 

Moreover, we might need to move workloads from the cloud in the US to China in the future.

As we're migrating and doing the Elite upgrade, which is an in-place upgrade, we find it great. We use it for databases, and we're testing it for applications. Some applications don't work, but some are functioning well. So far, it's been a positive experience.

Since I'm more focused on migrating, Leapp is awesome. We are able to do something that will work the way it's working.  There are no issues or breaks.

RHEL's knowledge base is great. It's very good. Especially when you try to open a case, it gives you all the options you need, so you don't have to wait for the case to be opened. You can get all the information you need right there.

Moreover, I am in the process of testing Leapp and Red Hat Insights. And then create our images from there rather than create MIs.

At the new company, we've been using it for three years. At my previous company,  we used it for over five years. Personally, I have been using it for almost eight to ten years.

We often have to go through people who have the same labels as us and who have the same knowledge base articles as us, which takes time. But they do it first; it's searching the knowledge way that I search. That I can do. That takes the time before. They do the payment. They sent me exactly what I had already found. And then we can go to the next level. That is taking a little bit more time that we can be a little bit better. So, the initial step of the support process could be improved. 

90% of people who open those bases are administrators who already look on the Internet for all these knowledge bases. So by the time we get there, we're gonna get the knowledge base back. And that's not helpful. 

Positive

I used to use HPUX and Solaris. We switched to RHEL because HPUX started looking like it was going away, so we started moving to Red Hat. We thought it was our best option. We tested different flavors of RHEL.

When it comes to provisioning and patching, we have a satellite server. We use a lot of Ansible. We are getting used to Ansible and Satellite servers. 

The initial setup wasn't complex, but since we wanted to make it easier to use, it became harder to make it work the way we wanted. Not out of the box, so we can just build a server that is ready to be deployed right away without any more interventions.

We use RHEL with AWS because it's easier for us to maintain since we create our own AMIs and we update that as we need it. So we don't need to follow their schedule until we get it more secure and more reliable for us.

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