Red Hat Enterprise Linux (RHEL) Reviews

Our primary use case is to develop the servers and production. It's pretty standard usage. We have some Docker running but I haven't been involved in those environments very often. It's a standard server on minimal load and we're not using a full load with our GUI interface.

We have multiple applications running on both Windows and RHEL. The database systems are mostly MySQL. There's some Oracle but most of it is MySQL. Dealing with Red Hat is pretty straightforward. I haven't run into issues with it. 

When we were running multiple versions of Java, if patches came out for both versions, we would apply the patches for both versions and usually, that could be downloaded. It was pretty simple to update those. Those are systems-supported patches. With the specific application patches, it's a little different. Normally the application administrators take care of those themselves.

If Red Hat's system is set up right, it improves the speed and performance reliability of our hardware because it doesn't use as many resources as a Windows system.

I like the fact that most of the system configuration is Namespace so it's easy to get to and easy to configure, and most of it still uses text documents. Not all of it's a menu-driven-type entry. I also like the fact that it's a very standard file system layout so it's easy to navigate.

In some instances, it provides features that help speed development. In other instances, it's standard amongst most Linux groups. You can download the main features. The file system is always a big difference. You go from a Debian-based system to Red Hat, so the file system layout is a little bit different. User-based files are located versus system-based files. RHEL keeps everything in one area and segregates it. It makes it easier to go between different organizations and still have the same policies and structure. I do like the new package manager.

It's all text-based, all command line, whereas the minimal load does not have a GUI on it. If you're used to using Windows core servers, it wouldn't be that big of a deal, but going from a Windows GUI-based system to an RHEL command-line-based system is a learning curve for most Windows administrators. A lot of strictly Windows administrators don't even want to look at a command line from Red Hat because the commands are so different from what they're used to. There is a learning curve between the two major platforms.

The application and user experience are usually pretty consistent, but that really depends on the application developer. If they're developing an application, it'll be consistent costs on infrastructure. That's not an issue between the different platforms. User experience is based on how the application developer built it. They're not all in-house and so they developed across a consistent platform. They keep everything pretty simple from the user perspective.

It enables us to deploy current applications and merging workloads across physical hardware and VMs. Virtualization and physical hardware stay consistent. Going to the cloud depends on the platform we use but it'll mostly be consistent as well. The RHEL distribution has been implemented pretty well amongst most of our cloud providers. It's pretty standard now, whether we go to Rackspace, Amazon, Azure, or even Microsoft supporting RHEL distribution. You can go to a Microsoft Azure cloud and have a Red Hat Enterprise Linux system running there. The user would probably never notice it.

For Red Hat, the bare metal and virtualized environments are pretty reliable. The only thing I don't like about Red Hat is that every time you do an update, there are patches every month and you have to reboot the system. Fortunately, it's a single reboot versus Microsoft, which likes multiple reboots, but still, you have to reboot the system. You have to reboot the server. The newer updates have kernel patches involved in them. To implement that new kernel, you have to reboot the system, and Red Hat's best policy and best practices are to reboot the system after patching.

I used the AppStream feature a couple of times. Not a whole lot because a lot of our environment is specific to what we deploy. Normally I would just deploy the bare system, adding features requested by the application administrator, and they'll download the rest of the things that they need.

We have used the tracing and monitoring tools in certain instances but not consistently. We use them for troubleshooting but not every day. We use other third-party software to monitor the system logs and alert on the issues. They will run tracing analysis of the systems. The reason we don't always use it is because of the number of servers I have to deal with and the low band power.

Automation is however you set it up. As for running a cloud-based solution, a lot of it would be automated. Going from prior experience, dealing with it before coming to this company, we did a lot of cloud deployment and it's pretty consistent and reliable and you could automate it pretty easily. 

RHEL accelerated the deployment of cloud-based workloads in my previous experiences. Compared to no other solution at all, it's obviously a vast improvement. You have to worry about Windows. As soon as you bring the server up, it requires numerous patches and it'll take several reboots unless you have an image that is very patched and deployable there. Even then, every month you get new patches. Red Hat patches a lot faster than Windows and requires a single reboot. The speed of deployment is a hazard. It's almost twice as fast deploying an RHEL solution as it is a Windows solution.

I'd like to see more of NCurses type menu systems in some instances. We're dealing with SUSE Enterprise Linux, they have an NCurses menu system. It's a menu system. Even some of the higher-end Unix systems like AIX have some inner menu system where all the configuration tools are right there so your administrator doesn't have to jump through multiple directories to configure files if needed. I like the simplicity of Red Hat because it's pretty easy but having an NCurses menu when you have to get something done quickly would be nice.

I started using Red Hat back in 1996. I've been using it for at least 20 years, off and on. I was hired as a Linux administrator for RHEL 6, 7, and 8, and then I changed my job positions. I'm not actively using RHEL right now.

Unfortunately, we're moving away from RHEL to Oracle Enterprise Linux in the next couple of months.

RHEL is a very stable product. It's been around for a long time now. It's been stable since they brought it out as an enterprise environment. It's usually not the bleeding edge of Linux. That just means it has more stability in the packaging and the repositories. They keep the bleeding edge updates and things out of it most of the time, which means if you have new features that you want to implement, you have to do some finagling to get those features in place. But it does mean the system's more stable, for the most part.

It's very scalable. I haven't seen any issues with the scalability of Red Hat. I've used it in environments where we have a few hundred people to a couple of thousand people. I've never seen any issues with scalability. It's one of the big sell points of RHEL. It's as scalable as Unix.

There are around 500 developers who use it. Web-facing interfaces, it's in the thousands.

If you're using a small environment with no more than around 100 to 200 servers, one or two people can handle most of the RHEL stuff pretty quickly.

If it's a larger environment, then you're looking at staff upwards from six to 15, depending on the environment the product's being used for.

There is a system administrator to perform the initial deployment of a server to the maintenance of the server. Then there are the application developers who develop the application, write the applications, and just manage applications. In our environment, we currently have sysadmins who manage the systems. My job is to manage the actual operating system itself. Then, you have application developers, who develop applications for user-facing systems. The application managers manage those applications, not only the developed applications.

It's being used pretty extensively. It's 1,100 to 1,200 servers on one site. 

We're using at least 85-90% of the features of RHEL but we don't really use Ansible that extensively. Red Hat Satellite server we're using as a primary repository in one site. Based on RHEL, we use most of these features.

We are switching to another solution mainly because a number of databases in use are based on that system. They want to expand that database and some other products that come with switching from RHEL to LEL. That's the main reason. As I understand it, the licensing isn't that different with a more centralized approach, so convenience is a large factor.

We switched to RHEL from AIX because of the developer and the cost. AIX is usually implemented on specific hardware. IBM owned the hardware. So the cost for running AIX is a lot more expensive than running an RHEL solution, which can be run on virtual systems as well as physical systems. And x86 servers are a lot cheaper than a power system.

Open-source was also a factor in our decision to switch to RHEL. Open-source has allowed a lot of development in areas, more ingenuity, innovation, and products than other constricted OSs. My opinion is that when you're dealing with open-source, you have people who are more likely to innovate and create new things. It's easier to develop an open-source platform than it is to use a closed source platform because then you can't get to the APIs, you can't do anything in the system if you want to change things in the system to make your product more available to people.

The initial setup was pretty straightforward. I've even set servers up at home on a pretty regular basis. I have my own lab, so I've deployed it and it's pretty straightforward. With RHEL, the setup is nice because you get a GUI, so any Windows-based user is going to be familiar with the GUI and know what to look at. They can deploy software as needed, right there from the menu. From a TextBase, you can script it to where all you have to do is run a script and it'll deploy the server quickly. It's pretty straightforward.

Personally, I wouldn't be able to speak to the installation. Having a single point is always a benefit because then you don't have to jump around multiple points to download software and to deploy your solution. The only thing about it is with Docker, a lot of times you have to go out to the Docker site to download the newest versions.

If you're running Satellite, it's even easier because all your current patches are downloaded. The iOS is already there and a lot of time is it's a straight script that you can deploy quickly. The single-point install is a good thing.

Depending on what you're running it on and what kind of equipment you're running, it can take anywhere between 20 minutes to an hour. That depends on the equipment.

They had Unix admins on site. They were implemented to bring in the Red Hat environment because of the similarity between Unix and Red Hat.

If you implement Ansible, that's an additional cost. If you implement Satellite, that's an additional cost to your licensing. However, the amount of licensing if you license 100 servers is actually cheaper per server than licensing 50 or 25.

The first one that comes to mind as a real competitor would be SUSE. It's built-in Germany. Ubuntu is a commendable product but I don't find it as reliable or as easy to administer as I do RHEL. A lot of developers like it because it's really easy. It's more geared towards a home-user environment than it is a corporate environment. The support factor for RHEL is good. If you need to call tech support, it's there.

I have used Satellite and Ansible in other environments. Satellite integrates very well. It's built by Red Hat, so it integrates thoroughly and it allows a single point of download for all patches and any software deployments you have. You can automate server builds, if you do it right, and make things a lot easier.

Ansible can tie into Satellite and RHEL fairly easily. It allows you to build multiple types of deployments for multiple solutions, and allows a playbook-type deal. You develop a playbook and send it out and it builds a server for the user. Done.

It would speed up deployment and make it easier to manage. If you had a developer who needed to throw up a box real quick to check something, he could run a playbook, throw up a server and rather quickly do what he needed to do. Then dismiss the server and all resource reviews return back to the YUM. If it was hardware, it would be a little bit different, but if we run a virtualization environment, they return all resources back to the host. So it made matching servers and deployment a lot simpler and less work on the operations environment.

The best advice I could give is if you're going from a Windows environment to an RHEL environment, there's a learning curve that is going to be a factor during implementation management and basic administration. Your company would probably need to hire new people just to support an RHEL environment. Between SUSE and RHEL, the number of people who know SUSE very well in the US is not as high as it is in Europe. RHEL has become more of a global OS than SUSE, though they're both comparable. I would advise looking at what you need it to do and then make sure you have the infrastructure, people, and manpower to support it.

There's a huge number of resources out there. You have sites geared specifically for RHEL administration. I believe IT Central Station has some resources on its site as well. There are Usenet groups and different forums. TechRepublic has a large number of resources as well. There are numerous resources out there to ease the learning curve.

There are a lot of things I've learned over the years using RHEL. Running it as a virtual design environment where you can run multiple servers on a single hardware piece makes it a lot more cost-effective and you don't have the resource depletion as you would have with Windows. Unfortunately, Windows is a resource hog. RHEL can be set up to run very minimally, with virtually no overhead other than the applications you're using to service users. 

I would rate it a nine out of ten.

We mainly use RPM-based systems to give our developers virtual machines.

The most valuable features of using RHEL for us are the standard way to run Linux and tools like NetworkManager. They make things easier for us.

I prefer a product that offers everything in a yearly subscription, like VMware, and I think RHEL should consider offering it as well.

I have been using RHEL for 15 years.

The scalability of the solution is good.

We use RHEL deployed in different zones, only on-premise, not in the cloud. Deploying RHEL depends on the end user, but migrations aren't usually a problem due to site forwards. The hardest part is dealing with end-user applications on the machines. We use Ansible for scripting, especially with Oracle. Sometimes, meeting the end of life for RHEL versions is tough, and we have had to buy extended support for RHE because some applications reached the end of life within a year. I appreciate the extended support option, though I prefer not to use it.

RHEL's pricing and licensing are quite expensive. For a big company, paying these fees might be manageable, but as a government organization, spending tax money on such expensive solutions is challenging, even though we do have the funds.

I see benefits in using RHEL because it offers stability and long-term support. Although we use both RHEL and Ubuntu, I have noticed that updates in Ubuntu can change things unexpectedly within a main release, which I don't like. That is why I focus on RHEL for its consistent and reliable updates.

RHEL's built-in security features are very good for risk reduction, business continuity, and maintaining compliance. We apply security guidelines in Linux using RHEL, which provides all the necessary baselines. We can choose and apply what we need directly to our RHEL systems.

I would say that open-source cloud-based operating systems like Debian are stable and have been around for a long time. There is a whole community supporting it, making it a strong alternative to RHEL with fewer licensing costs.

Overall, I would rate RHEL as a nine out of ten.

We are using Red Hat Enterprise Linux for running solutions, such as database solutions, and enterprise, web, and network applications.

One of the fundamental reasons Red Hat 7 has benefited our organization is that it is fully certified. It has certifications on the DISA STG and other cybersecurity frameworks like Zero Trust. This is what the Department of Defense mandates to be used and it is feasible to receive these specifications and automate the implementation for continuous improvement. By implementing the technical guides, we can receive immediate results and protect environments according to our expectations. There are a group of technical procedures that are shared and that you can implement, if you follow the industry best practices.

The most valuable features are the specification and technical guides, they are most important for cyber security assurance

The accessibility to the resources could be more widespread. The registration of the license information is complicated and this product registration process should be easier for customers to access.

In an upcoming release, they could improve by having more focused security.

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

The solution is highly stable.

Red Hat Enterprise Linux is perfectly scalable. You have some resource limits depending on how you're using the technologies. According to those usage patterns, the system is going to be able to give more or less. However, this depends more on the user side than on the system side.

We have approximately 10,000 enterprise users using the systems. They sporadically log into the applications and make use of the database systems and extract information. 

There is a division between the paid support and the support that is included by the website of Red Hat. I have only used the website support and there is a lot of documentation available.

Positive

I have used other Linux products, such as AWS Linux, Debian Linux, and Ubuntu.

The initial setup is straightforward for our use case. As long as you understand what you're doing, the technologies that are involved, the proper way to style, secure, and prepare them, everything will be fine.

After you have the guide, the printed procedure, the deployment is straightforward. The operating system can be deployed in less than an hour.

Okay, and how long did the deployment take?

The solution requires maintenance, and it is a shared responsibility. They take different maintenance actions or tasks, and sometimes it's the operating system, database system, or application front band that needs maintenance.

The number one advice would be to keep the division between testing and production.

There's one system that you need to set up for testing purposes only, and this testing system can be obtained free of license. There's an evaluation license that can be easily applied. When developing the application on the Red Hat 7 system, stay using the evaluation version until the requirements are fully met, only then should you migrate them to a paid supported version.

The biggest lesson that you learn by using this solution is, you easily reach a point where a single person or a single team can no longer respond to the complexities and challenges of the security or the different versions of the applications. At that moment you need to rely on a serious fused team, that team that is backing the effort.

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

We are running databases and applications on it. We are also using the Squid proxy server, NGINX, and Apache, so we are running multiple services on the servers.

We are using Red Hat Enterprise Linux eight and nine. We also use Red Hat Satellite and Red Hat Ansible Tower.

I've mostly worked with the telcos and banking sectors, and they mostly have on-prem setups. We do have a hybrid environment where we have multiple machines running on AWS. I am based in Saudi, where they are using another cloud called Din. They are running Red Hat Enterprise Linux on Din as well.

Their trainings should be free.

It's more stable than the other operating systems. That's why everyone is using the Red Hat Enterprise Linux platform instead of Windows on the server side.

They regularly send us updates regarding patches and security vulnerabilities. We patch our servers quarterly. Mostly, we do patching every three months. They always send us updates on our official email, so it's quite good.

It would be very good if we can easily migrate from CentOS to Red Hat. We are about to move from CentOS to Red Hat. It would be great if they can give us a free version. Otherwise, we need to purchase licenses, which are quite expensive.

I've been using Red Hat Enterprise Linux for five to six years. I have only been working with Red Hat Enterprise Linux over these years.

Its stability is quite good. I'd rate it a nine out of ten.

I'd rate it a nine out of ten in terms of scalability. It's being used in the banking center, and they are running their applications and databases on it. 

We have LVM configurations, so according to the application, we can increase the disk size. The environment is quite good for my use.

Their support is quite good, and they're responsive, but they first send us to the platform to check the issues. They don't provide direct support immediately. For a new engineer, it can be quite difficult. It would be good if they put us directly on the call in case of an emergency.

Some of the newer engineers require support in a quick manner. Those of us who have experience of six to seven years don't require the support, but in the beginning, we required support, and their support was quite good.

Positive

The product selection depends on the company. Telco companies have the budget, and they are using licensed products, whereas small companies usually use the free versions of Linux. They go for Oracle Linux, CentOS, etc.

We are using CentOS and Ubuntu on some of the machines. The company wanted to go for a free product, but I told them that for any support in the future, we need a licensed product, and they are now migrating to Red Hat Enterprise Linux.

It's best in terms of security features. We configure the templates and then we implement the CIS controls, security features, and complete patching of the server.

In terms of maintenance, Red Hat provides us with the details about the security vulnerabilities, and the engineer needs to implement all the security on the servers.

We did it on our own.

We haven't seen an ROI.

From a management point of view, it's quite good, but everyone is complaining that it's more expensive than the other operating systems.

Overall, I'd rate Red Hat Enterprise Linux a nine out of ten.

We use the product for application hosting, availability, and CI/CD pipelines.

The solution has good availability and is easy to use. It saves money and resources like support staff.

The product should provide a portal to manage licenses.

I have been using the solution for more than five years.

The solution’s stability is fine.

The product’s scalability is fine.

The support is good.

Neutral

We have seen an ROI on maintenance. As long as our servers run, our company makes money.

We evaluated SLES and Windows.

We purchased the solution via a cloud provider. We use AWS, Google, and Azure. The resiliency of the product is the same as other products. 

The solution helped us reduce costs. We use SLES and Windows alongside Red Hat Enterprise Linux. Application support and vendor support for Red Hat Enterprise Linux are better than other products. 

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

I use the solution to build web applications.

The tool provides more support, resources, and documentation than other products.

The product is super easy to use.

The default settings are confusing. I often change these settings to avoid problems.

I have been using the solution for a couple of years.

The stability of the product is very good.

I did not have issues finding configurations and changing settings as needed. I haven't had any issues like bugs or downtime while using Red Hat Enterprise Linux. Overall, it was a good experience. Overall, I rate the solution an eight out of ten.

We use RHEL for database servers, a few of them run Oracle servers, and we are also using it for some of the network and infrastructure services.

The best operating system I've ever used is Red Hat, in terms of its ability and consistency of the operating system. Other than that, the vast majority of applications that I had, I could deploy those on Red Hat without much effort as it supported a vast majority of applications. I never faced any major issues with the OS, the support is also very good.

The most valuable features are:

• The stability and reliability of the OS itself
• Being open-source and leading the open-source market trends/ technologies
  
• The wide variety of applications we can deploy on Red Hat
• Their support 

I am a big fan of the OS and the user experience. They're very good. The OS is very stable and very good in performance as well.

RHEL enables us to deploy current applications and emerging workloads across all virtualized hybrid cloud and multi-cloud environments. It is one of the most stable OS that are available. 

We use RHEL to run multiple versions of the same applications and databases on a specific operating system. We have several deployments of database and a few of them are running on a bit older versions of Red Hat and some of them are running on newer versions. We are running different versions on different platforms. The management aspect is also very good, especially when we need updates on the different packages from the RH support network, management is easy.

We also use the tracing and monitoring tools to monitor OS as well as applications running on RHEL platform. The OpenShift is also a big plus through which you can manage and deploy enterprise-ready containerized workloads.

Being an advocate of open source technologies I always wished that Red Hat subscription/ support should be offered free of cost. Having said that, I understand the economics involved in running large enterprise like Red Hat; support cost is one area that can be improved. They should offer it at reduced prices.

I have been using RHEL since the start of my technical career, which was around the mid of 2003. So it's been almost 18+ years. I started using RH when it was version 7.

Stability has always been a plus for RHEL. 

Scalability is excellent. With the introduction of hybrid and multi-cloud support, one can scale up as well as scale out his workloads pretty easily. We usually scale up our traditional workloads when we need more resources i.e., during peak seasons. 

Four people in my team are responsible for deployment and support of Linux based workloads. 

We have around 300 virtual machines (VMs) and roughly 20% of them are running on Linux environment.

Whenever I open a case, I believe the support team will be able to solve my problem. They are very good at it. The documentation RHEL provides is also very good. Almost all the time, I get a solution to my problem. :)

We are using other flavors of Linux OSes, that include Oracle Enterprise Linux (OEL) and CentOS, both of which are binary compatible with RHEL. We are also using a couple of other Linux flavors like Ubuntu and OpenSUSE.

RHEL provides features that help speed our deployment. Installing on a physical server takes more time than installing it onto a virtual machine (VM).

Because of absence of local support in our part of the region, we did find some difficulties in the initial deployments with hardware vendors/ partners when we started in 2003. The local partners didn't have much knowledge of Linux environments at that time, and the support for hardware was also a bit tricky. The deployment took a couple of days until we got support from the hardware manufacturer.

Nowadays, it's very good. I managed to get good support from the hardware vendors after that incident.

We have our own deployment plans for the operating systems that include some baseline configurations and security checklists.

We usually deploy in-house as we have a trained team. Occasionally, little help is sought from the vendor teams, some of them have skilled professionals.

RHEL offers an efficient, cost-effective and reliable OS environment for enterprise-level environments. Similarly cost of running operations and the scalability factors make RHEL a good choice for providing a better ROI. The feature set it offers, support for a variety of applications, ease of deployment, and an excellent level of support all result in a good ROI. 

I believe for an enterprise-level operating system and the feature set RHEL offers, it's like any other enterprise platform cost. The introduction of OpenShift is also a big plus in terms of deployment and management of container based workloads. Red Hat as mentioned earlier can improve a bit on support/ subscription costs.

We had been using a couple of Red Hat variants for some scientific experiments that included Scientific Linux CERN (SLC) and Scientific Linux (SL), which were a confidence booster for choosing and deploying RHEL for production workloads.

Since I started with version RH 7, I believe the GUI is quite close to any other GUI operating system. There have always been a variety of tools and features that attract a non-Linux user.  As already mentioned, RHEL has been a pioneer in open-source technologies; it continued to evolve with changing market needs, that has been a big success for them.

I would definitely advise choosing RHEL if you need stability, scalability, and reliability of the OS platform. I would be a big advocate for the use of Red Hat to any new person who wants to deploy his production workloads, on-prem or on cloud on a Linux environment.

I would rate it a nine out of ten. It's near perfect. 

It started mostly with websites and open source environments overall for development. Now, we are moving into business applications as we are migrating our ERP, which is a cp -r tree, to Linux. We are also migrating the database of SAP to SAP HANA on Red Hat Enterprise Linux. 

We use RHEL versions 7 and 8. There is a bit of version 6 still lying around, but we are working on eradicating that. It is mostly RHEL Standard subscriptions, but there are a few Premium subscriptions, depending on how critical the applications are.

It has fulfilled all the promises or goals of different projects, not just because our internal team is strong, but also because our external partner is strong.

Satellite is an optional system which provides for extensive deployment and patch management. That is quite valuable.

We use Red Hat Enterprise Linux's tracing and monitoring tools. You don't leave them on all the time, as far as tracing is concerned. When you are sick and go to the doctor, that is when you use it, e.g., when an application is sick or things are really unexplainable. It gives you a good wealth of information. In regards to monitoring, we are using them to a point. We are using Insights and Insight Sender as well as the Performance Co-Pilot (PCP), which is more something we look at once in a while. 

Other Red Hat products integrate with Red Hat Enterprise Linux very well. In fact, they integrate with pretty much everything around the universe. We are doing API calls without even knowing what an API is, i.e., towards VMware vCenter as well as Centreon. There are certain individuals who use it for free without subscription and support for Ansible in our Telco group with great success.

Linux overall needs improvement. They cannot go much beyond what Linus Torvalds's kernel implementation can do. I come from AIX, and there were very cool things in AIX that I am missing dearly, e.g., being able to support not only adding, but also reducing memory and number of processors. That is not supported on Linux right now, and it is the same for the mainstream file systems supported by Red Hat. There is no way of reducing a file system or logical volume. Whereas, in AIX, it was a shoo-in. These are the little things where we can say, "Ah, we are missing AIX for that."

We are not loving our servers anymore. If we need them, we create them. When we don't need them, we delete them. That is what they are. They are just commodities. They are just a transient product.

I have been using it for nine years, since 2012.

The stability has been very good. However, there is a learning curve. We were running huge in-memory databases, about 2.5 terabytes of RAM, which is SAP HANA. Then, we were getting really weird problems, so we asked the app guys 20,000 times to open a ticket because we were seeing all kinds of weird timeouts and things like that on the OS side. We were saying, "It's the app. It takes forever." Finally, they said, "Oh yeah, we use a back-level thing that is buggy and creates a problem." It took us six months and four people to get that from the app guys. We were ready to kill them. That was not good. Whatever you put on Linux, make sure that you have somebody supporting it who is not dumb, or on any platform for that matter.

The scalability is six terabytes. That is what we're doing. We are printing HANA servers on that scale, which are more in the 2.5 terabyte range. However, we had to create one for the migration initiative on the VMware, which was six terabytes with 112 cores. It worked, and that was it. It also works with bare-metal, but you have to be aware there are challenges in regards to drivers and things.

RHEL provides features that help our speed deployment. For example, for SAP HANA, they have full-fledged support for failover clustering using Red Hat HA, which is a solution to create a vintage approach of failover clustering. They do provide extensive support for value-adds for ERP solutions.

They also provide value left, right, and center. Whenever we have a problem, they are always there. We have used both their professional services as well as their Technical Account Manager (TAM) services, which is a premium service to manage the different challenges that we have had within our business. They have always come through for us, and it is a great organization overall.

Their support is wonderful. They will go beyond what is supposed to be supported. For example, we had a ransomware attack. They went 20 times above what we were expecting of them, using software provided by them on a pro bono basis, meaning take it and do whatever you want with it, but it was not ours. That was a nice surprise. So, whenever we have needed them, they did not come with a bill. They came with support, listening, and solutions. That is what we expect of a partner, and that is what they are: a partner.

I, for one, was managing AIX, which is a legacy Unix, as my core competency. I still do because we haven't completed the migration. 

RHEL is a value-add right now. As we are migrating more payloads to containers, we are putting less Linux forethought into these container-hosting servers. You just shove your containers on top of them with your orchestrations. This may reduce our need to manage RHEL like a bunch of containers. That changes the business. 

We were paying for premium SUSE support for an initial pilot of SAP HANA on the IBM POWER platform. We were stuck between an IBM organization telling us, "Go to SUSE for your support," and the SUSE organization saying, "Go to IBM for your support." So, we told them both to go away. 

We are so glad that we haven't mixed the Red Hat and IBM more, because SUSE and IBM don't mix, and we were mixing them. That was prior to the merger with Red Hat. In regards to IBM's ownership of Red Hat, we are a bit wary, but we think that IBM will have the wisdom not to mess it up, but we will see. There is a risk.

The initial setup is as straightforward as it can get for anyone who knows what they are talking about. It does require technical knowledge, because that's what it is: a technical solution. It is not something that I would give to my mother. Contrary to other people's perception of, "My mom had a problem with her Windows. Oh, put her on Linux." Yeah, no thanks. Give her a tablet, please. Tablets are pretty cool for non-techies, and even for techies to a certain extent. 

For the migration from AIX, Ansible has been our savior. You do need somebody who knows Ansible, then it is more about printing your servers. So, you press on the print button, then you give it to the apps guys, but you do have to know what you are trying to aim for so the guy who is creating the Ansible Playbook codes exactly what is required with the right variables. After that, it is just a question of shoving that into production. It is pretty wonderful.

We do get a return on investment with this solution in regards to a comparative cost of ownership of going with the niche solution of IBM AIX systems and hardware. There is a tremendous difference in cost. It is about tenfold.

The integrated solution approach reduces our TCO tremendously because we are able to focus on innovation instead of operations.

RHEL is a great place to go. They have a great thing that is not very well-known, which is called the Learning Subscription, which is a one-year all-you-can-drink access to all of their online self-paced courses as well as their certifications. While it is a premium to have the certifications as well, it is very cool to have that because you end up as a Red Hat certified engineer in a hurry. It is good to have the training because then you are fully versed in doing the Red Hat approach to the equation, which is a no-nonsense approach.

Because it is a subscription, you can go elastic. This means you can buy a year, then you can skip a year. It is not like when you buy something. You don't buy it. You are paying for the support on something, and if you don't pay for the support on something, there is no shame because there are no upfront costs. It changes the equation. However, we have such growth right now on the Linux platform that we are reusing and scavenging these licenses. From a business standpoint, not having to buy, but just having to pay for maintenance, changes a lot of the calculations.

We tried SUSE on the IBM POWER platform, and it was a very lonely place to be in. That was for SAP HANA migration. We are glad that we decided to be mainstream with leveraging what we already had at Red Hat Linux (over a few dead bodies now). We also leveraged the Intel x86 platform, which is very mainstream. 

We are not using the Red Hat Virtualization product. We are using VMware just so we can conform to the corporate portfolio.

Our RHEL alerting and operation dashboard is not our route one right now. We have been using Centreon, which is derived from the Nagios approach, for about seven years.

With AIX, we couldn't get a single software open source to run. It was like a write-off, except for reducing a file system or logical volume in Linux.

We are a bunch of techies here. RHEL is not managed by end users. We don't really mind the GUIs, because the first thing that we do is stop using them. We are using Ansible, which is now part of RHEL, and that can automate the living heck out of everything. For now, we are not using the Power approach, but we may in the future. We are doing a business case for that, as it would be an easy sell for some communities and the use cases are not techie-to-techies.

There is a cloud, but we have very little infrastructure as a service in the cloud right now. 

It delivers to the targeted audiences. Could Red Hat Enterprise Linux be used in all types of other scenarios? Most likely. They have an embedded version for microcontrollers, i.e., things that you put into your jewelry or light switches. However, this is not what they're aiming for.

I would rate RHEL as a nine and a half (out of 10), but I will round that up to 10.