Red Hat Enterprise Linux (RHEL) Reviews

I work in infrastructure. We have various use cases for Red Hat Enterprise Linux. We use it for the compute feature, which runs on some applications on the front end and databases on the back end.

LVM is a valuable feature. It enables us to dynamically increase the file systems or logical volumes. My journey with this feature started 10 to 12 years ago. 

LVM is the reason why I started using the solution initially. Nowadays, there are a lot of applications. We can use clustering, security, and optimize security.

The product's availability is on the main cloud hyperscalers, like GCP, IBM Cloud, Azure, and AWS. The product should be made available on Oracle Cloud. 

I would like to see Ansible as a default in future releases.

I have been using the solution for 13 to 14 years.

Although some questions are not business-critical and high priority, they are still urgent. The support identifies such questions as P3 or P4 incidents. Although there's no business impact, we depend on the support team for answers.

Neutral

We have used SUSE Linux. We have also used open-source tools like Ubuntu, Fedora, and CentOS. We switched to Red Hat Enterprise Linux due to its vast exposure to security vulnerabilities. Its support model, subscription model, and its support for HANA are valuable.

We use the product on-premise, on IBM Cloud, and on Azure. The subscription model of the solution enables us to use hybrid environments. We can enjoy the benefits of the hybrid environment with the bring-your-own-subscription model.

We have plans for upgrades. We have a legacy Red Hat Enterprise Linux. One of the customers has version 5. We are trying to build an upgrade plan for it. We would like to know whether we can directly land on version 9 or if we should go step by step to each version.

The solution's built-in security features are exciting. I like that the solution covers the recent vulnerabilities in the CVEs. The solution should continue to do that.

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

We use Red Hat Enterprise Linux for off-the-shelf applications and Oracle databases. 

The tool is simple and easy to use. It has good support and doesn't have many outages due to the OS. 

The cockpit server doesn't work and is useless. I don't like the images shown in GCP. I prefer the ones in AWS. It seems like the solution is in tune with what we deploy on the private cloud. 

I have been using the solution for ten years. 

We open a case whenever we need support. Whenever I need support, I contact the technical guy assigned to us and provide him with the documentation. 

Positive

I have used different OS like Motorola, Unix Flavors, Solaris, HP-UX, AIX, DG/UX, and Sonos OS. Unix is dying, and everything is moving to Linux. Linux is open-source and easier to use. 

We build our own deployment method. 

Red Hat Enterprise Linux is expensive. We have changed the cloud provider's subscription to a pay-as-you-go model. 

We use the on-premise, cloud, and hybrid versions. We have deployed it on AWS, Microsoft Azure, and Google Cloud. Most of our infrastructure is in the Azure cloud. I work in the server infrastructure team, and other data collectors work on AWS and GCP. We haven't used the tool's features like the image builder. 

The product supports our hybrid cloud strategy. We have been migrating using tools from Microsoft Azure. Its knowledge base is good. Sometimes, finding an article is difficult. However, once I reach them, it contains good information. 

We used Azure's tools for migration to the cloud. It is straightforward. We have no problems deploying the servers. Our main strategy focused on data centers.

We use the Leapp tool to manage the upgrades. It works smoothly on our Oracle databases. Leapp is straightforward to use. 

We use Red Hat Insights quite a bit. I have not explored all the features yet. We use it to look for events our monitoring hasn't picked up. It also helps us with tips and hints for fine-tuning applications like SAP and Oracle. We go by these recommendations and follow them to put the applications in place. I have downloaded the Playbooks for remediation. 

I use system rules for SAP tuning in Oracle. I do not use the image builder since we already have a process to do the server builds. I use the web console once in a while. 

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

We primarily use it for OS purposes. 

It's very good for support compared to other operating systems. For decades, it's been providing good support and service. Even during implementation, there's a dedicated team to answer any queries. We are a very big company running critical applications and having that support is very important.

The patching tool is good. We're also introducing the possibility of automation.

The built-in security features are okay when it comes to simplifying risk reduction. It makes life easier, especially in regards to the lifecycle and what we need to install, et cetera. The features and tools help us to maintain security overall. 

It is easy to maintain compliance.

The portability of applications and containers is good. Now we are just starting with the containers and anything related to Kubernetes. 

Red Hat is always providing security on time. Any vulnerabilities are immediately dealt with to fill the gap and deal with the issue.

It's a good tool. I'm very confident with this product.

The system role features for automation security configurations, et cetera, for Ansible, we started using it. We are new in terms of automation. We'll start to use it heavily in the near future. Ansible is another great tool from Red Hat.

It enables us to maintain consistency across systems over time. My role is to maintain stability, even during upgrades and patches. So far, it's been a positive experience. We use the entire ecosystem around Red Hat.

We use Red Hat Insights. From a security perspective, we may stop using it. With Insight, if you have Red Hat Satellite, it gives you an in-depth view of everything. The only thing missing is the insights related to performance. We may not continue with it. We'll see if we'll push it and have everything on the cloud. 

In the area we are using it, we are satisfied.

Maybe in OpenShift, which is our next step, there can be more improvements with integration with Kubernetes. We're not experts there yet. 

Maybe it could have a better user experience and less coding. Reducing the effort for the end user or administrator would be ideal to make daily operation and maintenance easier. 

If they can make the integration with Ansible easier, that would be ideal.

They should offer more in terms of learning materials to make learning easier. 

They need to make things more affordable or accessible. 

The solution is stable. We barely have any issues with a server setup. So far, it's manageable. The biggest challenge is the criticality of releasing patches. When we have any critical alerts we action them. We tend to try to wait for the release of a stable version. 

How many people use the solution depends on the application. We likely have thousands of users. We do have some products that maybe only have a few or a few hundred. 

We've had no challenges with scaling. It can support any type of load within the data center. 

Support is excellent. 

Positive

We did use a different OS. I have used Unix in the past. I started with Unix 30 years ago. I've also used SUSE. Red Hat offered more service and support. 

I was involved in the deployment. Our team managed the process. It's pretty straightforward. We handle implementation, tuning, and patching. 

How long it takes to implement the product depends. We're trying to mitigate the time by automating with Ansible. We want to handle one VM or server in five or fewer minutes, however, it can take days. At this point, we can provision servers in a few minutes. It's becoming faster. 

We have a team of ten to run the infrastructure on the OS level. 

I'm not an expert on ROI. We are paying to use the solution, however, the utilization we get and the support both offer good value. 

The pricing model isn't something I deal with directly. The pricing is fair, especially compared to virtualization like VMware. We do use VMware and are thinking about moving sandboxes and testing over to Red Hat. This may end up being a big cost savings with our CAPEX and OPEX. 

From the price level, the cost is almost the same for us, if we look at Red Hat versus SUSE, however, we get a higher level of support with Red Hat. 

Red Hat was always our first choice. 

We're a Red Hat customer. 

I'd rate the solution nine out of ten. 

I provide consultation to clients for their mission-critical applications. Its primary use case is running containers and microservices on Springboard.

My customers use versions 7.2 or 7.3. I have used versions 8.2 and 8.4. I have tried version 9, but I use version 8.4 specifically because it supports HighPoint RAID for storing the data, whereas the client applications run on the much lower version.

There are benefits in terms of price, security, and stability to reduce the risk of applications going down or something like that. A vast majority of systems are on Red Hat Enterprise Linux than on other distributions, which is another benefit.

Red Hat Enterprise Linux helps to achieve security standards certification. They use it in the PCI DSS segment, so it enables the applications to be compliant with all these security aspects.

Red Hat Enterprise Linux is very stable. It has been in the market for many years, and it is used by large organizations.

Their documentation and knowledge base are valuable. As an individual developer, whenever I have problems, it is easy to find the information. Their knowledge base is seamlessly integrated with the software. Whenever I have a question, it directly takes me to the knowledge base. It is well documented.

It supports scripting very well. Everything is scripted. A snapshot is taken in the VM, and the script is applied. It lends itself to better security and governance processes.

Its installation on a RAID or cluster system is something difficult. There are specific teams working on that. The GRUB configuration is also a little different from the other Linux distributions. 

In terms of additional features, as technology keeps evolving, the product will also have to evolve. For example, Microsoft Windows has come a long way. In Windows 11, there are so many features that are fundamentally the same as the oldest version, but there are other aspects or processes that have improved. macOS has also evolved over time. Similarly, in the Red Hat Enterprise Linux that I used in 2003 and the one that I am using now, some things are the same and some things have changed. Red Hat can continue to engage clients, understand the use cases, and update them.

I have been using Red Hat Enterprise Linux since 2002 or 2003. Red Hat has a vast variety of products. I have only been using Red Hat's operating system. I have not used Red Hat's other products.

It is very stable.

It is scalable, but I do not have experience in building hundreds of systems on a VM.

I have not used their technical support at all. I only use their documentation portal for self-support. Our production support team interacts with Red Hat's support team.

As a developer, I use both SUSE as well as Red Hat Enterprise Linux. My personal preference is Gentoo, but no one runs Gentoo on a production system. Gentoo is better in terms of customization. You can choose what you want.

I am not directly involved in its deployment, but I am planning to build an application. At that time, I will be deploying it myself. In the organization where I work as a consultant, there is a segregation of roles. There is a production support team, there is a development team, and there is a DevOps team. I am a part of the development team.

Its initial setup is straightforward. It is not complex. It also depends on the architecture, high availability, etc.

In terms of deployment, earlier, it was on-prem, but now, it is on the cloud. My client runs about 150 VMs on the cloud in the production, staging, and QA environments. Most of the things have been consolidated into VMs. The migration is complete. It was not that complex.

I have not measured that, but it should pay back for itself easily. The ROI should be reasonable. The cost over a period of time should be minuscule. As compared to other OSs, it is better to go with a big, known, and trusted vendor.

As a developer, I pay around 10,000 Yen, which is around $100 per annum for support. SUSE and Red Hat are typically the same without standard support. The pricing is not a big deal. Enterprise customers will pay for the support. Enterprises have the money for one or two products like this that are reliable and supported.

As a consultant, I advise customers to go for support. You mitigate risks by having support. For your personal usage, you can manage without support, but when it comes to the enterprise level, you need to delegate things to people, and it should be through the proper channel. You need a proper point of contact.

I would advise following the best practices recommended by Red Hat. It will minimize the downtime of the application or system. Partner with the vendor and get that support. Know the business case and build a strong relationship with the vendor. Trust them and tell them your use case, and they will come up with the best solution possible.

I am not a big authority on Red Hat or other Linux or Unix products. Only recently, I have been exposed to the concept called hardening and penetration testing. I do not know whether Red Hat provides a hardened version of the OS. My basic distribution is Gentoo which provides a hardened version of Linux. On the client side, the organizations we work with have different departments, such as the security department and the compliance department. For security, they work with various options that are available. For penetration testing, we engage a penetration testing consultancy company once a year.

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

We use Red Hat Enterprise Linux as an infrastructure support operating system across both x86 and s390 platforms. Specifically, we are running it on x86 Intel and Linux s390 mainframe on Zynq.

Red Hat Enterprise Linux is a stable operating system. We recently upgraded the majority of our systems from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. We were able to automate most of the upgrade process and did not encounter any major issues. As a result, we were able to bring our systems up to date quickly and easily. This is a major advantage of using Red Hat Enterprise Linux.

From an automation standpoint, we have been able to automate some of our patching workflows. This has definitely saved us time and money.

From a security and compliance standpoint, it is easy to maintain compliance. This is mostly accomplished by patching Red Hat Enterprise Linux on a frequent basis. The availability of security patches is also quick, which allows us to keep up with our client requirements quickly. Red Hat usually does a good job of making fixes available in a timely fashion, so we can remediate high-priority issues when they arise.

From a containerization standpoint, Docker and Podman now give us the ability to move workloads and structures around with little effort. It is very flexible and consistent, and the results also provide us with a stepping stone as we move towards an orchestration platform like OpenShift. Our ability to run Podman on servers and then migrate those Podman deployments to OpenShift is very beneficial.

The most valuable features are ease of support and the ability to run a read-only course on the operating system.

Red Hat Enterprise Linux is easy to maintain. We currently use Red Hat Enterprise Linux 7 with Docker for containerization. With Red Hat Enterprise Linux 8, we are moving to Podman, which is a native container runtime that is part of the operating system. 

I suggest that Red Hat move to a continuous delivery model instead of major releases. I know that this is a trend for many middleware products. We do not have a major release network. We only have monthly or quarterly roll-on releases on our continuous delivery model, which reduces the impact of a major version. This would probably be the easiest change to make.

The technical support has room for improvement.

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

Red Hat Enterprise Linux is stable.

Since we run a number of hypervisors for all of our real systems, I believe that a lot of the scalability comes from a level higher than the operating system. However, Red Hat Enterprise Linux can accommodate these tools.

Red Hat support could be improved, and they should have a better relationship with IBM and VMware. This is because a lot of what we do involves working with IBM, both from a hardware standpoint and from a hypervisor standpoint. We have a long history with IBM, and we are now starting to work more with Red Hat on OpenShift private cloud solutions and other tooling. However, Red Hat and IBM are not on the same page. They are still very different companies, and they don't always know what the other one is doing. This can lead to contradictory information, inaccurate information, and frustration for customers. I think there is a relationship between Red Hat and IBM that could be improved. If Red Hat and IBM could work together more effectively, it would put customers at ease and make them more confident that they could get the work done. It would also help IBM and Red Hat to better understand each other's products and services, which would lead to better customer support.

For example, we recently had an incident that started as a severity two on the scaling. A number of our account representatives called and emailed us, saying, "Hey, we wanted to let you know that you have an open case. We need some help with this." The incident was not a production outage, but it was preventing us from doing something, so there was an indirect production impact. After about ninety minutes of back-and-forth communication, we were told, "Okay, go ahead and bump it up to severity one. That should get traction." We did not hear from anyone for four hours. This does not happen every time, but in this case, it needed to be dealt with well before four hours. It made things more difficult than they needed to be. Sometimes the support is an eight out of ten, and sometimes it is a four.

The end result was still good because they acknowledged what happened and got everyone together to resolve it but it was not done in an efficient way.

Neutral

The initial setup of Red Hat Enterprise Linux is very straightforward. It is not much different from any other Linux operating system. Most of the things we need to consider when deploying Linux are relatively standard. Therefore, Red Hat Enterprise Linux is easy to deploy and maintain. If we know how to administer Linux operationally, then Red Hat Enterprise Linux should be easy to deploy.

I do not know enough to give a comprehensive answer, but other operating systems are in use at my company because they have more favorable licensing terms. This is a major factor in why we do not use Red Hat Enterprise Linux everywhere.

We evaluated SUSE Linux Enterprise and a few others. Depending on the computing platform, it is sometimes better and sometimes not. For some of our environments that are running on s390, SUSE Linux Enterprise gives us a better price point. However, for some of our other environments, such as x86 on VMware, it is more valuable. It is a better financial move for us in those cases. Therefore, the value of SUSE Linux Enterprise changes depending on the computing architecture.

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

We have a requirement to have a Linux operating system.

I'm not sure how our developers are building their images. I believe they use some desk start products.

We use SUSE Linux Enterprise for Linux on the mainframe. In a particular enclave, we have some government contracts where we use Red Hat Enterprise Linux for a number of reasons, including licensing for hosts. These hosts are hosted with OpenShift. We use Red Hat Enterprise Linux for all our Bastion hosts and OLS for our other hosts.

The Red Hat knowledge base is generally an eight or nine out of ten, but it can be difficult to get the information we need. The initial level of support is a six or seven, but it improves as we escalate the issue.

I am a Federal Contractor. Red Hat Enterprise Linux is one of the FedRAMP-approved operating systems, so the government is comfortable with using it. That is why we use it, even though it is a bit outdated. Most of our software runs on Red Hat Enterprise Linux because we work in Identity Access Management. For example, Oracle Identity Stack runs on Linux, so we have to use Red Hat Enterprise Linux. We follow very strict security protocols, and we use Ansible to enforce them. Red Hat Enterprise Linux is the easiest way for us to do this.

Red Hat Enterprise Linux is a trustworthy and highly scalable operating system. The federal government needs an operating system that they can rely on, with enterprise support and long-term service. As well as being stable and well-known within the community.

I have not yet experienced a disaster recovery scenario, but resiliency is important, and risk is very reliable. The auto logs are very clear. Additionally, with those support communities, it is straightforward enough to understand what we are looking for and to eventually resolve the issue.

I actually like the in-place upgrade that Red Hat Enterprise Linux offers. It has made our upgrade process from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 much easier than we originally thought. 

I know that many people prefer in-house support, but I personally prefer Red Hat's support. It is easy to get in contact with their support team.

Even though it is not directly related, the fact that Red Hat Enterprise Linux and Ansible are closely related makes it easier for us to move forward.

The package management, repository, and satellite repository are easy to use.

I am a bit biased because my client is air-gapped. This means that we cannot connect to the internet, so all of our operations are disconnected. I would like to see better support for disconnected operations. For example, the in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 initially relies on a lot of online resources. This makes sense, but it would be nice for a consumer or integrator like me to be able to say, "Hey, we need an offline solution so we can upgrade our government clients on-premises." Red Hat does provide instructions on how to create a repository, but the instructions are not very clear. This leaves us scrambling to figure out why we are missing a repository in our satellite image. Red Hat should provide a way to mirror repositories or at least provide a solution for us to bubble up packages throughout the entire process.

I have been using Red Hat Enterprise Linux for four years. We started with Red Hat Enterprise Linux 6, and we upgraded to Red Hat Enterprise Linux 7 in an airgap environment. We are currently in the process of upgrading to Red Hat Enterprise Linux 8.

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is scalable. It is deployed in a 10,000-plus enterprise company.

The support team is always direct and easy to find. Their answers are so helpful that I have not yet had to call them. I also appreciate how they approach troubleshooting. They don't assume that you're doing anything wrong. Instead, they try to educate you on how to fix the problem. In my experience, the support team has always been very positive.

Positive

I have experience with most Linux operating systems, including distributions like Apache, Debian, CentOS, Fedora, and others. From my perspective, Red Hat Enterprise Linux is not necessarily the top standout product, but I know that it is a product that I can rely on. It is the standard image that enterprise users in the community will use. We can rely to a degree on the standardization of how packets are used to support it. However, it does not stand out to us as much as the other products. Nevertheless, I know that it will have a positive partnership with us. Red Hat Enterprise Linux is a more suitable operating system for enterprise environments in terms of stability and reliability.

We are currently in the process of reviewing our initial solution for upgrading from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. The in-place upgrade for the airgap environment is an area where we are still struggling to understand the documentation. However, Red Hat has been very supportive and has offered us pathways to move forward. We do not have much to say at this time, as we are still in the middle of the process.

When we upgraded Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7, it took us around six months due to external factors not related to Red Hat Enterprise Linux.

Our client has a direct subscription to Red Hat.

I give Red Hat Enterprise Linux an eight out of ten. I am not a firm believer that everything is perfect right out of the gate. Everything can be improved. I am a little biased. I wish there was better support for offline environments. I understand that I am in the minority in this case, as everyone is connected to the internet now. However, as a federal contractor and integrator, we have requirements that we must meet. It is not fun having to download binaries offline and then figure out how to set up our own repository. These are not straightforward tasks like Red Hat telling me what to do. We just wish it was easier to do things like patch management. Perhaps there could be more support for air gap environments. These are not environments where we can temporarily connect to the internet. They have never seen the internet.

Depending on our customer's environment, sometimes they have GovCloud, but we still use Red Hat Enterprise Linux images there. Sometimes the customer can't use that so we use the offering from CentOS. But we still try to match it with CentOS.

The reason why some clients don't use Red Hat Enterprise Linux on the cloud is not because of security concerns. I think it's more about cost and their current contract situation. They need a low-cost, open source alternative, and our recommendation would be CentOS. However, many clients are not ready to pay for the enterprise edition of Red Hat Enterprise Linux, so they may choose to scale back their plans.

I have not used the Red Hat Enterprise Linux knowledge base strictly. I have only used the Red Hat Enterprise Linux support.

Clients who use Red Hat Enterprise Linux on the cloud, typically use AWS GovCloud. As a government integrator, we strive to design our solutions in a way that does not lock our clients into any specific cloud provider. This is why we chose Linux, as it can be run on any cloud platform. This flexibility is important to our clients from a price contract perspective. For example, Amazon provides Kubernetes services, among other things. We try to figure out open source solutions or at least architecturally determine them and provide them to our clients. For example, we can tell them that they can move all of their GovCloud data to Azure or Google Cloud. Government agencies really like Amazon right now because it is FedRAMP. However, for other classes that are not government or commercial, we try to introduce them to the CentOS perspective so that they can get a taste of the upstream.

We do not use the image builder tool provided by Red Hat. Instead, we use the one provided by Amazon. We take a base image, coordinate it with Ansible, and provide it to any environments that have used the cloud. For on-premises solutions, we strictly use manual processes.

I don't have a perspective on the golden image, which is at least with our client. The parts that we use are always evolving, so we don't really maintain the golden image. We do have a relative backup of what we deployed to, but we don't necessarily have a strict golden image.

Migrating workloads between the cloud and the data center using Red Hat Enterprise Linux is not entirely applicable to us. We did migrate from on-premises to the cloud at one point, but migrating from Red Hat Enterprise Linux on-premises to Red Hat Enterprise Linux in the cloud was not a concern for us. We knew it would be stable and fine. The main concern was migrating our customer data from our enterprise to the cloud.

If someone is looking for an open source cloud-based operating system for Linux instead of Red Hat Enterprise Linux, I would like to eventually drive them over to Red Hat Enterprise Linux, but I would recommend starting with CentOS. CentOS is a good gateway OS because it is very similar to Red Hat Enterprise Linux, and the knowledge transfer between the two is very straightforward. This makes it a good choice for users who are new to Linux, or who are looking for an OS that is compatible with Red Hat Enterprise Linux.

I use it for almost everything. I run a company in South Texas and Mexico. We are a cloud service provider, and we have implementations for almost everything. We are using it for websites, virtualization, orchestration, and containers, and we are also using it a lot for telecommunications. We use almost all of its features.

We have many versions. We have versions 8, 9, 9, 9.1, 9.2, etc. 

When we implemented all the security frameworks with RHEL three years ago, that was the first time we had a non-issue audit. It was a great implementation.

It helps with the headcount. With the kind of orchestration and automation that we have, we don't need a lot of engineers. We can have fewer engineers on site.

There is reliability. We can rely not only on their operating system but also on their server. Red Hat not only has operating systems; it also has many different servers.

It helps to achieve security standards certification. It is one of the most important things that I do every single day. We need to comply with a lot of frameworks of security, such as ISO2701, ISO2717, ISO2721, PCI compliance, and HIPAA for the health sector. We also have some local compliance requirements. For example, in Texas, there is one for financial entities, and in Mexico, there are several based on GDPR. It is very important for us.

It is helpful when it comes to building with confidence and ensuring availability across physical, virtual, and cloud infrastructures. There are many features to ensure or enforce high availability.

It helps us to centralize development with OpenShift. We don't do a lot of DevOps, but we have a supply chain where everything goes to the on-premises cloud, and then it is pulled to the public cloud.

The Red Hat support is most valuable. My team and I are really good at Linux, and we can do almost everything in any kind of Linux solution, but sometimes, we have a really nasty problem, and the Red Hat engineering support at the third level has been fantastic. They know how to fix almost everything. The reason why I pay so much money to them is to have this kind of service and assurance.

Containers are the strongest feature that they have. In terms of the quality, between VMs and containers, Red Hat with OpenShift is fantastic. I have more than a million containers right now in my cloud, and it works fantastically.

Network virtualization resources could be better. When you have any kind of trouble with network virtualization, such as with OVS, which is like a switch in a virtual environment, it takes many hours to find what is happening. Other vendors, such as VMware, and even other Linux implementations for network virtualization have better resources. It is much easier to escalate, and there is better documentation.

I don't use Ceph, which is their software-defined storage, because they don't have the best price. It doesn't make sense when you compare it in terms of the hardware cost, better performance, and better capabilities. That's my main complaint at any meeting with Red Hat. I want to use Red Hat Ceph, but it costs so much money.

I have been using it for about 20 years.

If you have the correct hardware, it is stable, but if you do not, you will have a problem any time soon.

It is reliable. If you don't know how to secure your Linux implementation, Red Hat can do it for you with two or three simple clicks, and you will be very secure without any kind of knowledge.

It is scalable. It is not the most scalable in the Linux area, but for 99% of the companies, it is scalable enough for any kind of workload.

We have plenty of clusters, and we probably have more than 400 servers. We are a private cloud solution provider. We don't have anything in the hyper-scale, such as AWS, Azure, etc. We own everything: the data center servers, racks, networking, and storage. That's our competency, and this way, we can provide a better solution to the kind of customers we are focused on.

We have three different locations: one in the states and two in Mexico. At each location, we have at least three different clusters for three different market verticals. We have one for the financial, one for the healthcare system, which has a lot of compliance requirements, and one for the general public, which doesn't have too much sophistication.

We plan to increase its usage, but it is not my decision. If I sell more, I will buy more.

They are exceptional. We have a lot of experience in these matters. Usually, when we have any kind of issue, it is a really difficult one, and I need to talk to somebody at level two or three in the support area. They skip the line for us because we send everything perfectly documented to open the PR. They put us in touch with the best engineer to solve the issue. If the engineer isn't able to understand what is happening, usually, he calls the RHEL developer or engineer that handles that part of the code. They are usually able to fix a complex problem in less than eight hours.

Their support is fantastic. I have dealt with many different vendors, but Red Hat is the only one that does it in this way. They do it in a simple and fast way. They understand you, and they are willing to help you and fix everything. If you have a problem or situation that is causing downtime for the customer, they understand that it has an impact on your business, and they are affecting the revenue of the company. They are really committed to fixing it as soon as possible. I would rate them a 10 out of 10.

Positive

We use RHEL and Canonical. We have some SUSE implementation in the Linux area. In hypervisors, we use VMware and Hyper-V. So, we are in many different technologies, and we are not always on RHEL. RHEL has almost 45% of all our hardware. It is the biggest one, but we use almost all the solutions. In terms of security, Red Hat and Canonical have almost the same level of security.

I am no longer involved in its deployment. I last deployed it about four years ago.

In terms of maintenance, every server requires some kind of maintenance, but we have everything automated. We don't put any effort into it. 

We have 8 to 12 people for deployment and maintenance. They handle the deployment and change of the environment in the data center. For DevOps, I have another team of probably 30 people. They develop solutions for customers.

We have definitely seen an ROI. The return on investments comes in the 14th or 15th month.

For the basic operating system, its price is fair. It is not cheap, and it is also not expensive. For the OpenShift or OpenStack implementation, the cost is a little higher than what I would expect, but it is doable. For a storage solution, it is almost impossible to pay.

In comparison to open-source competitors, RHEL has the most cost-effective open-source subscription model. The way I pay for everything, such as Ubuntu or RHEL, is very similar. When you compare how much money I put in for a customer, in terms of licensing, or even support, my margins with RHEL are really good. If I compare it with VMware or Hyper-V, which are not open source, the difference is totally insane.

I am a vendor-agnostic solution provider. If my customer needs something with RHEL or something that's specifically with another vendor, I use that. If they don't know, or there is a new implementation, I surely send everything to the RHEL implementation. In the end, this is not my decision. It is a market decision. If my customer is telling me that they should be on RHEL, I will bring in RHEL for them.

I would advise paying for the enterprise-level support at least for the first year.
For sure, it is expensive, but it would be helpful. With experience, you can downgrade to the second level.

We have had some issues with container compression that broke everything. So, I don't recommend using it if you don't know how to fix everything.

The biggest lesson that I've learned from using this solution is to read before starting the implementation.

I would rate it a 9 out of 10 because there is nothing perfect.

I use it as an EC2 Web Server.

It was needed for FedRAMP Moderate compliance.

The ready-to-go AMI is a valuable feature.

It does not pass the RHEL8 STIG standards without a lot of extra work.

I have used the solution for one year.

I previously used CIS RHEL 8 Level 2.

Check it to verify costs.

I did not consider any alternate solutions.

It does not pass the RHEL8 STIG standards without a lot of extra work.