What is our primary use case?
We're using it to support security applications. We also use it for various infrastructure aspects, such as hosting Satellite or Ansible Automation or Confluence. We have a mix of different apps running on it.
How has it helped my organization?
Our improvement as an organization, from using RHEL, has been the ability to take the stance of an infrastructure-as-code approach. We've seen that with automation of server deployment, getting them spun up a lot faster. Traditionally, the environment was using Satellite and Kickstart. Regardless of whether we were bare metal or virtual, it could take a couple of hours to Kickstart a server. Moving to infrastructure-as-code and deploying a server takes about 10 minutes until it's ready to use. It's a lot faster.
In addition to Satellite, we're using Ansible Tower. Those are the only ones we're paying for. We use other products, like Red Hat IDM for identity management but that's part of RHEL. When it comes to the integration between these products and RHEL, we're able to use Satellite for our dynamic inventory, with Ansible to help deploy new servers or manage servers, and we use Ansible Tower to patch our servers. Everything works pretty well.
That integration has helped to improve things compared to how they were when I got here. For example, we have a more automated process for patching. As we develop it and work through issues, we hope it will be more of a pipeline and a lot easier and faster, compared to how it was done before. Similarly for building servers, now that we're able to use Satellite as our dynamic inventory, we're able to run Ansible, whether it's predefined playbooks or ad hoc, without having to do something manually or maintain an inventory file.
We also use the AppStream feature in some cases. We have a couple of applications that require different versions, and we're able to install it and it makes the requirements for those specific applications.
What is most valuable?
The most valuable features are
- stability
- supportability.
Those have been the two common and important features over the years. They're pretty equal. You want to have something that's up and running and stable, something that's not going to crash. But if we do have an issue, we can get somebody for technical support who can help us work through the problems.
As for the consistency of application and user experience, we spin it up and almost forget about it. It just does what it's supposed to do, regardless of the underlying infrastructure. It's all good and there are no issues as far as supporting applications or things crashing go. Because it's doing what it's supposed to do, it's not a source of concern.
And similarly, there are no issues when it comes to deploying current applications and emerging workloads across bare metal, virtualized, hybrid cloud, and multi-cloud environments. We just have to take note of whatever the requirements are for the application we're deploying, to make sure requirements are met, and then build a server based on those requirements.
In this environment, I'm not doing any cloud work, but in my last environment we did do a bunch of public and private cloud and we had no issues there. It worked fine and as expected in AWS and OpenStack. We were doing infrastructure-as-code in that environment as well. We would create an image-base, whether for AWS or OpenStack, and then we would automate the deployment again, using Terraform and Ansible for configuration. It made deployment of cloud-based workloads relatively quick.
What needs improvement?
My biggest issue right now is Red Hat Consulting and trying to use some of their services to help get us going. Technically, they're good, but we seem to have issues with scheduling.
Also, we initially deployed it with Red Hat Satellite. We're now moving more to automation using Terraform within VMware, to automate the clone and then follow up with Ansible to configure. Red Hat's standard deployment is with Satellite and Kickstart, but we're looking at other options to help speed it along. We do have a mix of bare metal and virtualized servers and it's easier to spin up in the virtualized world versus bare metal. That's why we're looking at some options outside of Red Hat, for the bare metal. We'd like something that we can use to build a server a lot faster, as well as address network latency issues.
For how long have I used the solution?
I have been using Red Hat Enterprise Linux (RHEL) since version 4 or even before that, since 2000 or 2001, before it was RHEL.
What do I think about the stability of the solution?
In the environment I'm in right now, we've never had any issues. It's very stable.
In another environment that I worked in, we had some Oracle Databases, but that wasn't really an issue with the operating system. It was more an issue with some configuration items between the database and the OS. And that was about four years ago.
What do I think about the scalability of the solution?
In the last company I worked for we were deploying a PasS environment, where we were doing some stuff with containers, and RHEL worked well. In my current environment, it's more of an application base but, again, it seems to scale. Both have worked fine.
How are customer service and support?
Red Hat's tech support has been pretty good. I'll open up a ticket to see if I can get information from Red Hat when I don't have the time to find it on my own. But 99 percent of the time we get great support and we're able to get the answers that we need.
How would you rate customer service and support?
What's my experience with pricing, setup cost, and licensing?
The pricing is fair. We do a bunch of dev work and there is some free dev licensing out there that's great for doing proof of concept work. When that was brought out a couple of years ago we heard about it, but it didn't seem to have been communicated to our Red Hat representative. We would ask him about it and it seemed that they were confused.
But the cost has been pretty stable over the years for what you get.
We figure out what we need for servers, make our purchase, and then manage it all in Satellite. We just make sure we're using what we pay for.
Which other solutions did I evaluate?
In the past, I've used other versions of Unix, such as Solaris and HP-UX, as far as paid versions go. In other environments we also used community versions, like CentOS and Oracle Linux.
Oracle Linux would probably be the closest thing to a paid solution, although I think it's free. But using Oracle Linux wasn't a good experience. Dealing with Oracle support was not the best. Maybe it has improved, but it just wasn't the same as Red Hat support.
What other advice do I have?
Times have changed from when I first started using it. Back then it was just a matter of putting a CD in and installing it. One of the companies I worked for did a lot of homegrown stuff and I used their tools that were like Kickstart. Now it is all automation with infrastructure-as-code. The complexity of deployment is about the same. Some of what we're doing to deploy stuff is outside of Red Hat and it's a matter of finding what tools are available.
We're in the process of deploying something right now where we have different versions of Python. That's the only use case we have with multiple versions on the same server. I don't expect any issues, but it's still early in that deployment.
We have three people dedicated to maintaining the infrastructure environment that we work in. That includes managing Linux servers, the applications that go with them, and dealing with day-to-day tasks like patching. It's the typical life cycle maintenance functions: break/fix, dealing with hardware issues, deploying new applications, and maintaining a VMware environment.
The reason we're using it is because it's stable and we know we can get support. I know there are other versions of Linux, ones that I've used, but I've never experienced the kind of support with those versions that Red Hat has provided. Red Hat is a stable Linux solution provider.
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.