Red Hat Enterprise Linux (RHEL) is just a piece of an operating system for my company, and what we need the most is STIG compliance because we have a lot of different customers.

Red Hat Enterprise Linux (RHEL) has helped my company since, with it, we have gotten more customers. Now, our company can say upfront that we use Red Hat and are STIG compliant while also being security-focused, which really helps open up the door to people who want to get their stuff done.

The most valuable feature of the solution is its good integration with Ansible.

Red Hat Enterprise Linux has not helped centralize development in our company, especially since we deal with unique use cases in our organization. My company still develops locally on CentOS, but once our company actually completes the product for our customer, it gets shipped somewhere else and we can't centralize things since we don't have that much time to spare owing to which we stay disconnected after the aforementioned process.

My company plans to use the product for containerization projects, especially since we are in the process of converting to Kubernetes.

Based on my assessment of the the built-in security features when it comes to areas like risk reduction, business continuity, and compliance, I would say that I am a big fan of the tool.

In terms of the portability of applications and containers built on Red Hat Enterprise Linux (RHEL) to keep our organization agile, it has been pretty good since all the containers have been very portable without having to deal with any environmental issues.

If I had to give a suggestion to a colleague who is looking at open-source cloud-based operating systems for Linux instead of Red Hat Enterprise Linux (RHEL), I would say that one should look at AlmaLinux since it is the closest thing one can get to Red Hat.

The product's deployment model is usually in a single data center, and it consists of one machine at a time. Red Hat Enterprise Linux (RHEL) does not use a public cloud.

The documentation is an area of concern where improvements are required. Sometimes, I go to look at stuff in the tool's documentation to see how to configure something, and it doesn't make any sense. The tool's documentation is written by someone who already knows how it works for those who need to learn how it works. Everything else in the documentation is really good, though. I would describe the documentation as a kind of a hit or miss.

I have been using Red Hat Enterprise Linux (RHEL) for about six months.

It is a scalable solution.

I would like to expand the use of the product in the future, but our company's business model is contract-based and very slow, which makes it difficult to work with Red Hat Enterprise Linux (RHEL).

As per my evaluation of the technical support offered by the product, I would consider the support services offered to be at a 50-50 rate since everything really depends on who you get to talk to from the support team. Some of the people from the product's support team to whom we reached out didn't understand our use cases or our problems, so they couldn't help us at all. Some of the support staff members who understood what our company meant when it came to the issues associated with the product were able to help us in 30 seconds. My colleagues who contacted the product's support team were satisfied with the technical team's services. I rate the technical support a six out of ten.

Neutral

In my company, we used to use CentOS. Now that CentOS has reached the end of life phase, it doesn't meet our company's needs, so we transitioned to Red Hat Enterprise Linux (RHEL).

Previously in my company, we used to use CentOS. CentOS will reach the end of life phase in the upcoming month, which is the reason why my company had to choose another product like Red Hat Enterprise Linux (RHEL).

The solution is used on an on-premises model.

Deploying Red Hat Enterprise Linux (RHEL) was surprisingly easy. The installers were the same as the ones used for other solutions.

My company did not have a strategy to deploy the product since we just needed Red Hat to hurry up, put it on a box, and figure it out.

My company did not seek the help of a third party to help us with the product's deployment phase.

The biggest ROI I have experienced from the use of the solution revolves around the area of customer satisfaction. My company's customers who use the product have a lot less to be changed in the product and it has helped save a lot of development and redevelopment time for our organization.

The cost and setup are not areas that are transparent for me. The tool's licensing part has been a real pain because when our company sells a system to a customer, they take full control of it in their data center, and we are not allowed to access it, even though they bought it from us. The license transfer has always been really awkward because our company initially had the license until our customers tested it and accepted the product. I was hoping to find somebody to talk to about the license transfer part with Red Hat products, but I don't know where to find someone associated with the solution.

My company briefly evaluated a product named Debian, but after that, our company's customers specifically asked us to go for Red Hat Enterprise Linux (RHEL).

Considering that the licensing part associated with the product is a pain, I rate the tool a seven out of ten.

Most of our infrastructure is made up of Linux servers. All of the apps that we have published are running on a Linux system. That is the main functionality.

I am responsible for Ansible for automation, and I am also responsible for our Satellite server, which is for patching and things like that. We use Red Hat Enterprise Linux a lot. We have 80% Red Hat Enterprise Linux and 20% Windows.

The benefits have been in terms of the speed and how the operating system does not interfere with apps that are running on it. That is the best aspect, at least from a business point of view. Databases run smoother, and so do the applications we have. There is no latency or issues like that.

We have a small number of servers up in the cloud in AWS, and then most of our servers are on-prem. We have a data server. Red Hat Enterprise Linux has made the deployment of servers smoother. We can do that pretty much with the click of a button, especially using AWS's platform.

For security and compliance, we have to be in sync with our security team. We cannot leave anything open. In Ansible, we have set up an actual configuration management playbook where it keeps all of our systems security compliant. It is really cool. Right now, we only have it working on our Dev and QA environments. We have not moved past that because we still have Chef. We are trying to get off of Chef completely. As of now, we are a hybrid. We have Chef and Ansible. Eventually, we will be completely Red Hat Ansible.

When it comes to keeping our organization agile, it is easy to decommission servers. Most of it is on VM, so we can just delete and then rebuild. If we accidentally delete a server, we can always bring it back because of backups and things like that. That is possible because of VMs. We do not have OpenShift, so I cannot say that Red Hat is the one that is keeping us agile.

The feature that I am enjoying right now is the actual LEAP program that they created for the actual in-place upgrades. I am upgrading from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. We are in the process of that, so that is the best functionality right now. It never had that ability in the past. That addition has been an amazing aspect.

I am not too sure how it could be better. I have not yet used Red Hat Enterprise Linux 9, so I cannot say if there have been any changes or improvements. Honestly, I cannot see it getting any better. I like the way the operating system works now, and I do not really see any bad functionality with it.

The only thing I would say is getting rid of some aspects. That is the one part that a lot of admins probably get annoyed with. For example, we are now going to DNF from using YUM. At some point, YUM will be taken away completely, but right now, you can use both. There are those minor tweaks, and you just have to roll with the punches. Maybe it is just a better version of what was there prior. DNF is probably used at a simpler level, and it probably does not take up as much configuration and space as YUM. I am not sure exactly why they make those changes, but that is probably the only thing that is kind of annoying.

In my current company, we recently switched from CentOS to Red Hat Enterprise Linux. We are also working with CentOS. It has been around three years with this company, but I have been using Red Hat Enterprise Linux a lot longer. I am a Linux admin and I have been using it since 2006 or 2007.

It is definitely stable. We never have any issues. Everyone wants to blame the patching or some change in the OS, but it is never that. It is always the other side.

It has a lot of scalability. We have plans to increase its usage. We are in the process of getting off Oracle Linux, which is, again, another version of theirs, but we are going to be converting those over to Red Hat. All of our databases are going to be running on Red Hat.

It is awesome. I just upgraded my Satellite server. I moved from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 and then also upgraded to Satellite 6.14, which is almost the most recent version. I did that in the last month. Their support was awesome. I worked through what was said in the documentation on how to do the upgrade. I created my own spreadsheet for the upgrade and what I needed to do. I worked with their support. I had a meeting with them to check if it would work and if anything needs to be added or taken away. They worked with us that way. Their support is awesome.

Positive

We had CentOS. It is still based on Red Hat.

We are just now starting to use Podman. We were using Docker, and we are now moving over to Podman, which is the Red Hat Enterprise Linux-specific version of containers. It has been an easy transition. We do not necessarily work with Podman. Application owners are the ones who want us to install it, and then they utilize it the way they want to.

We have three data centers. We have a data center in the East in Pittsburgh, and then we have one in Arizona. We also have it in the cloud in AWS. Even there, there are two, so we have four data centers.

We do have a few Red Hat Enterprise Linux systems on the cloud. We are not sure if we are going into the cloud completely, but we do have some servers in the cloud. Our cloud provider is AWS. Our main app resides in the cloud. All the data, most of the data servers, and other applications are on prem. 

I was involved in the deployment of Red Hat Enterprise Linux. We were the ones who converted it. It was very simple. Red Hat's technical person gave us the conversion script and tools. We just utilized that conversion script to switch from CentOS.

We did not use a consultant or an integrator. Red Hat gave us the tools, and we did it.

I do not know what the impact is financially because I am not in that department. For compliance, it has been helpful. Especially the banks have to be compliant in terms of being patched and things like that. Red Hat has been beneficial.

The biggest return on investment has been the ease. I have been a Linux admin for many years. I have used Solaris, AIX, CentOS, etc. I have always liked Red Hat Enterprise Linux better. It is just a better OS.

I do not know the overall cost, but I know that Red Hat is cheaper than Windows.

We did not evaluate any other solution. We were going to Red Hat Enterprise Linux.

We just switched from open source, which was CentOS, to Red Hat. My advice is to stick with Red Hat only because with open source, you do not get the updates at the same time. The updates come later for vulnerabilities and things like that. I would not recommend open source for an organization. If you are at home, you can go ahead and easily use CentOS. It is free, so why not use it? For an organization, Red Hat Enterprise Linux is better.

Currently, we are not using Red Hat Insights the way they are meant to be used. We are planning to do so at some point in the future. Currently, we only use it as a tool to make sure that it keeps track of all of our servers, whether we delete or add servers. Red Hat Insights keeps track of that and lets us know what version it is and things like that, but we do not utilize Red Hat Insights the way they are meant to be. Red Hat Insights provides vulnerability alerts and targeted guidance, but we use Nexpose for vulnerability scanning. 

Red Hat Enterprise Linux has not yet enabled us to centralize development. That is because of the way the company is structured. Everything is fragmented. We have a separate networking team. We have a separate Linux team and we have a separate software team. Getting something done and centralized is pretty much impossible at this point. Any small tweaks are like pulling teeth at this point. I do not know if that is going to change. Hopefully, it will. We are planning on moving to OpenShift. I am hoping that it will make everything more centralized and it will bring the company to a less fragmented spot.

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