Red Hat Enterprise Linux (RHEL) Reviews

The primary purpose of any operating system is to run all sorts of applications and databases on servers. We use RHEL to run applications and host containers but not much else. We don't use it for databases, and none of our clients use Red Hat virtualization, so no KBM. We install them onto VMware and use them like Red Hat virtual machines.

I primarily work for banks that tend to have a proper on-premise cloud because the data can't leave the premises. We also work for insurance companies, government, and law enforcement organizations. Most of them use it on a virtualized platform like VMware. Some are hardware installations, and other clients are experimenting with cloud infrastructure. One of the banks we work for has started to build its own cloud to get experience and move specific applications to the cloud.

One client has RHEL deployed across two data centers, which is usually a mirrored setup. In other words, two hardware servers are doing the same thing. It can be active-active or active-passive. The VMs also stretch across two data centers, but it's a Metro cluster, so it's in the same city. I've been working with my current client for a couple of years. Our three-person team manages 250 hardware services and about 400 VMs.

We are still migrating a couple of solutions to Red Hat, so the user base is getting bigger. 

We decided to use Red Hat Linux instead of Solaris or something else because it's widely used and accessible. It's easier to find people who know RHEL. It has also made the automation through Satellite and Puppet easier, which are built into Enterprise Linux. 

RHEL is stable, mature, and relatively easy to handle. I'm pretty confident in it. We haven't had to raise a serious support ticket for any server in I don't know how many years. It has built-in high availability solutions for VMware on top of the hardware.  

Red Hat Linux is also useful for keeping applications from misbehaving. I like the fact that it has firewall controls.

Red Hat can be tricky at times, but all operating systems are. The moves to systemd and NetworkManager haven't made the product more user-friendly. The network management they had before was easier and somewhat more reliable than NetworkManager, which Red Hat forces us to use now.

That may just be my personal preference because I've been working on Red Hat for so long. It's something new that doesn't do exactly what it used to do, so it's probably more of an old person's complaint.

The firewall controls can also be somewhat challenging in terms of automation. An application may use a different setup, so you need to consider that if you want to automate installations. 

You can't easily port an application to another operating system unless it's CentOS or Fedora. It's not portable if you want to port it to something like Windows except for Java and containers. Unless it's another Red Hat, CentOS, or Fedora, the application itself isn't portable if it's installed on a thick virtual or physical machine even. It's not easily portable because you must recompile the application or make changes.

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

There are bugs, but you can usually find a workaround quickly. When somebody discovers a bug, it's fixed pretty quickly in the next release.

The services run well, and it can handle pretty much anything provided you have enough hardware resources. That's something you always have to watch out for.

RHEL is so stable in the environments I've been working on that I have never had to call Red Hat. Any issues we've had were either hardware or application problems. It's never an issue with the operating system. 

The community resources are helpful. You can find answers to most questions you have in terms of setup or troubleshooting. There are issues now and again, but you can go to the website or a discussion board to find the solution, and it works. When I say we've never had a problem, it's not exactly true. Sometimes it doesn't do what you expect, but you can usually find the solution, so we have never had to call support to ask.

A lot of my clients used to use Oracle Solaris, but many of them switched to Red Hat due to hardware costs. Oracle hardware is expensive, but it is good stuff. We had systems that ran for three years without any issues, but it gets expensive if something breaks or you need to replace hardware due to the lifecycle. 

You can install RHEL on any x86 hardware and deploy it on several Dell servers, which is much cheaper than a single Oracle server. For example, we needed to replace a system because the hardware got sold. We were quoted a price for Solaris running on an Oracle T5. It was four times the price of replacing it with HP hardware. So that's the main reason many clients have shifted to RHEL. 

It's a vicious cycle. As more companies switch, other clients say, "Oh, but there's not much user base left. How long will this run? Let's follow the mainstream trend." That said, I love Solaris. It's unbelievably stable and easy to use, but just the hardware underneath it is too expensive.

I've been involved in deployment, but it depends on the client. I've done everything from architectural design to installation and administration for specific clients. Setting up RHEL is pretty straightforward if you know what you need to know. Of course, you have to do your homework before. For example, if you are deploying it on a VM, you need to see the size you need and what else you have to install. 

When someone orders a server, we typically tell them the deployment will take half a day, but the installation takes around an hour. You may need to install other things, but the out-of-the-box operating system takes about an hour.

We're just one team who manages the infrastructure for one department. It's highly specific. There's a specialized market team that does stock exchanges and financial services. The demands for hardware and availability are particular to that segment. We have three people responsible for installation, maintenance, and administration.

RHEL is stable and relatively cheap, so you get much more out of it than other Linux flavors. I mostly work as a consulting system engineer and am usually not involved in any of this financial stuff.

I can suggest how many subscriptions they need and how much it will cost, but I can't say if it's worth it to the client. I don't know, but we have never had any complaints. People never say, "Oh, but this is expensive, and it doesn't fit into what we had planned."

RHEL has a decent pricing model. It's a subscription, which makes sense. The OS itself is free, but you pay for the support. I have never heard any complaints about the pricing.

You can also purchase a virtual data center license that allows you to set up a hundred virtual servers. You can also add a Satellite license subscription to your standard server. There are several different add-ons that will increase the price of the subscription, depending on the functionality you need.

It's hard for me to compare Red Hat with other open-source solutions because we only have clients who work with Red Hat Linux. Of course, there are entirely free ones you could use. Fedora is the most extensive free version of Red Hat. You could use Ubuntu or any other Linux flavor, which is mostly free. However, I have no idea what additional cost you'd pay if you want to support.

I rate Red Hat Enterprise Linux nine out of ten. I would recommend it, but I need to qualify that by pointing out that I don't have enough experience with other Linux flavors to say that it's better than the others. I've mostly used RHEL because it's so ubiquitous.

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.

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.

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.

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.

I have been using Red Hat Enterprise Linux (RHEL) since version 4 or even before that, since 2000 or 2001, before it was RHEL.

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.

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.

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.

Positive

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.

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.

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.

We have various use cases with about 12,000 instances across four data centers and three different clouds. In general, it's for the adoption of and standardization with other vendors, so that other vendors' software is known to work. We're doing lift-and-shift of existing hardware infrastructure that is onsite into the Cloud.

It enables us to deploy current applications and emerging workloads across bare-metal, virtualized, hybrid cloud, and multi-cloud environments. Typically, there haven't been a lot of issues in terms of the reliability of applications across these environments.

The AppStream feature provides access to up-to-date languages and tools in a way that interoperates with third-party source code. It makes it a lot easier to maintain that, as well as keeps our developers happy by having newer versions of development languages available.

In addition, as we roll into version 8 and, upcoming, 9, it makes the migrating of older applications into these environments easier.

We also use Red Hat JBoss Fuse and Red Hat Insights, the latter being a part of RHEL. Red Hat products integrate greatly with the OS itself. We're pretty pleased with that. The integrated approach simplifies our operations to a great extent.

The most valuable features are the

• flexibility of the OS itself
• reliability
• support model.
  

Also, the two versions we use are fairly standard. Most of our applications work with versions 6, 7, and 8 meaning migration and maintainability are pretty good.

In addition, we run multiple versions of the same application on a specific operating system, between different instances. RHEL is great at managing and maintaining those different versions. It's so much easier, and it does it without destroying the operating system itself.

I don't see anything that needs improvement with RHEL itself, but there is room for improvement of the support infrastructure for it. The management and updates to Satellite, which is the support update, have been cumbersome at best, including releases and changes to a release. Communication on how that will work going forward has not been great.

I've been using Red Hat Enterprise Linux (RHEL) for about 20 years.

We chose Red Hat for the stability.

The scalability is really good too. In terms of increasing our usage, I can only foresee it becoming greater in the environment.

Sometimes the tech support is hit and miss, but most of the time they're really responsive and knowledgeable. If the first-line tech doesn't know something, they will escalate quickly.

If I were to compare the tech support from Dell, HP, and Red Hat, Red Hat is probably our best support structure.

Positive

I've been with my current company for 10 years. We've used other UNIX platforms, like Solaris and AIX, but those are for different use cases. The company I started at, which was bought, had seven different implementations and I standardized them on RHEL, before the acquisition.

We switched to RHEL because those seven different operating systems were supporting a single team and none of them had a great management infrastructure, or they were just plain open source with no support. And getting to a single, supported, managed environment was the goal.

Red Hat's open-source approach was a factor when we chose the solution. I'm a big fan of the entire open-source consortium. The more people there are who can look at the code, validate it, and make sure it works as it moves upstream into the solidified package that Red Hat supports, the better. It gives you more visibility, more transparency, and you can customize it more. Whereas with closed code, you have no idea what's going on in the background.

The initial setup of the solution is relatively simple. It's pretty much click, click, click, done. And the single subscription and install repository for all types of systems make the purchasing and installation processes easier.

Depending on the platform, deployment of a single RHEL instance could take anywhere from  five to 30 minutes. Bare metal is going to take longer than deploying the cloud.

The licensing is a subscription model and the only product whose model I don't like is Ansible. At $100 per server, with 12,000 servers, it adds up.

My biggest advice would be to read the documentation and reach out to Red Hat, or even just search the internet, so that you understand what you're getting into and what you're implementing.

I can't think of very much that needs to be improved with RHEL. The model that they have for maintaining patching, and their cadence on Zero-day attacks is fantastic, and their support is really good. I don't see any issues.

It's the operating system for different applications we have that are related to telecommunications such as VoIP, DNS, and many others including identity management.

We are using it based on virtualization, including VMware, Red Hat Virtualization, and we have some OpenShift Virtualization.

RHEL has improved things a lot when it comes to automation. Creating a virtual machine was not an issue, but when it comes to the post-configuration of the workload, the solution has made life way easier. For instance, we created an automation chain that creates a virtual machine from scratch right through until the post-configuration is done. We managed to group different applications in this one chain.

In terms of speeding deployment, we have playbooks that are supported by Red Hat, where we can automate deployment and configuration. That helps a lot, making things much faster. It has accelerated our deployment of cloud-based workloads because of the availability of the modules that help us to create playbooks for post-configuration. It's not only creating a VM but, after that, we still have to do the post-configuration manually; rather that's all automated now. Where post-configuration used to take one or two days, it now takes a couple of hours.

In addition, so far the applications are consistent, regardless of the infrastructure. That's especially true when you automate it. Even if you have an issue, the consistency of deployment helps a lot.

In addition to Red Hat Virtualization and Red Hat OpenShift, we use Red Hat Satellite. We decided to base our entire stack on Red Hat because most of the vendors we use want us to have our applications on the Red Hat operating system. With our whole stack on Red Hat, it makes communication easier because we aren't ping-ponged between different vendors. In addition, there is a good knowledge base for different Red Hat products. The integrated approach among Red Hat products has helped us in that when it comes to identity management, for instance, because we don't need to wonder if Microsoft will support this or not. It has also helped to automate patching as well.

The most valuable feature is the Identity Management. You pay almost the same subscription cost for normal RHEL and you get the central Identity Management. You would need to pay much more if you were using other applications or products like Active Directory from Microsoft.

It also enables you to deploy current applications and emerging workloads across bare-metal and private cloud, which are the only environments we have. The applications are very reliable, across these environments, with RHEL.

In addition, we use the solution for monitoring using the features like PCP and that is helpful indeed.

An area for improvement in RHEL has to do with security policies. I know they are doing something about this in RHEL 9, but I haven't worked with that version yet. When it comes to security policies in RHEL 8, it is a bit behind. It would be better if we could just enforce a certain security policy such as CIS Level 1. That was not available, out-of-the-box, in RHEL 8.

We have been using Red Hat Enterprise Linux (RHEL) since mid-2010.

If it works the first time, usually it will work forever. It's only when you patch that you need to do some regression testing to make sure that it's working.

We haven't had any issues with scalability at the OS level for years.

I'm very satisfied with the technical support for RHEL. They are helpful and knowledgeable. I don't have any complaints.

Positive

I used to have Ubuntu, but I didn't like it. The beauty of RHEL is that you can easily find support, unlike Ubuntu. While Ubuntu has free subscriptions, unlike RHEL, you cannot get support for Ubuntu easily.

With Ubuntu, when I had an issue, I would have to go to Stack Overflow and check the internet. With RHEL, I like that I can go to IRC and post my question and they answer me.

We are using Satellite, which is considered to be a subscription manager, in a way. In the beginning, it was complicated. Now, they have created something called Simple Content Access  (SCA). We buy a subscription for audit purposes and for legality to have a legitimate copy. On the other hand, Satellite itself issues subscriptions once you have a new OS system. That has made things way easier.

We used professional services back in 2009 or 2010. But once we found that every vendor was looking for Red Hat Enterprise Linux, we added that skill in our department and now we are doing everything ourselves.

Because it's a very stable solution, if you have the knowledge in-house, go for a regular subscription. Otherwise, buy the Premium Support.

We had some AppStream versions for different OSs, such as CentOS, but we decided to go for RHEL because it would make life easier in terms of lifecycle management. If we had RHEL and CentOS, it would make patching more complicated.

The biggest lesson I have learned with RHEL is don't complicate your design. You can always find an easier way to do things. Sometimes you'll think, "Oh, we can do this," and you start thinking about very complicated processes. It's better to think and start simple.

With RHEL, we have patching in place, automation in place, and we already know the support. We are very satisfied. We have done a lot of work on it and now it's easy to deploy VMs immediately. We are not looking to implement any other version of Linux.

We are primarily using it for services, such as cloud infrastructure services, for our business. We are working with a Town Council in Bolivia. We provide the environment for deployed applications, and we are using it for the private cloud, Linux server, and applications developed within the company.

Mostly, we use version 7.0. We also have three servers with version 8.5. We are working with everything on-premise. We have a cloud, but most of the cloud is accessible from inside the company. It is not accessible from outside of the company.

Red Hat at present is the core, and we are also using Ansible, Horizon, OpenShift, and Kubernetes in our environment. They are a part of our environment. It is the best in terms of integration, and it is totally integrated with other solutions. With these integrations, all other solutions become a part of one big solution, which saves time. You can achieve the same results by building things from scratch with open source, but it would be very time-consuming. Deployments become easy and fast because everything is integrated. It is very good to have everything integrated, and we now have just two people working with the whole infrastructure. 

It has accelerated deployment. We are using OpenShift, and it is very easy to deploy new machines on our infrastructure. Like Ansible, we can deploy many machines with the same configuration or automatic configuration. It is really fast. 

With Ansible, we can easily create environments. Comparing the infrastructure that we had while using Windows 2012 with the tools that we now have with Red Hat, we have saved 80% of the time. Everything is automated with Ansible. We only check playbooks. It has accelerated the deployment of applications. Automation saves time and allows us to allocate people to other work. Previously, it was very time-consuming to create environments. We had to train people. We had to create maybe three or four virtual machines for load balancing according to the needs of the client, whereas now, OpenShift is creating them automatically and destroying them when they are no longer needed. It saves a lot of our time. People are doing more technical work. In the past, we had five people to work with the infrastructure, and now, we have only two people. Three people have been moved to another department.

We can run multiple versions of applications for deployment. OpenShift has Kubernetes inside. So, you can run one version, and immediately, you can deploy the next version and do a test of two versions. We test new solutions or patches in an application, and we run both versions at the same time just to have a benchmark and prove that some issues have been fixed. With Kubernetes, it is easy for us.

Its scalability and ease of setup and configuration are most valuable. When we have a hardware failure, we just save the configuration files, and in about half an hour, we have another server running with the same configuration. It is really easy to replace servers. This is the best feature.

It has very good integrations. The IPA feature is really awesome. We used this feature to integrate with Active Directory. Red Hat has many tools for integrations.

I would like training to be added to the subscription. It would be useful for when you have to train yourself or get a certification. There are many things that we are not using because we don't know how to use them. Having training included in the subscription would help us in learning more things and utilizing the full power of the solution.

I have been using this solution since 2000. I have been using Red Hat before it became Enterprise, but in our company, we adopted Red Hat about two years ago. We still have a few servers on Windows Server 2019, but most of our servers are on Red Hat.

It is very reliable. We didn't have any issues with services.

Its scalability is good. We can work with the same server and make it a load balancer. It is really easy. In one hour or one and a half hours, we can have another server working, and we can put it in the cluster. It is really easy.

We contacted them only twice, and we received good support from them. I would rate them a nine out of 10. The only thing that is missing is the training. If they can include training in the subscription, it would be awesome.

We mostly had Microsoft solutions, and we were using Windows 2012, and we had some issues with it. Working with Windows was really painful for us as administrators. For users, there was no issue. The servers were always working. We switched to Red Hat because it had the biggest offering. It is an enterprise solution, and it gives you all the things. With others, you have to do things on your own. It is a complete solution.

When we migrated from Windows 2012 to Red Hat, it was a game-changer. In the beginning, we were working with IIS for deploying applications. Most of the applications were developed in the company, and some of them were not PHP-native.

We also have four servers using Debian Linux, and we have another software that is open-source and built from scratch. It is like Red Hat, but you need to do most of the things from scratch. We're using Docker instead of Kubernetes for everything related to quality assurance for our developers.

It was complex at the beginning because we only knew the basics. We didn't know the purpose of many of the tools and how to implement them. We started training ourselves. It took us two years to implement or to make this change.

We first installed it on a few of our servers, but then we started working with OpenShift. We have a private cloud in our infrastructure, and it is me and one colleague doing this job.

We haven't measured it, but we would have got an ROI. It is doing many things for us, and it must be providing a big return on investment.

If you don't buy the Red Hat subscription, you don't get technical support, and you don't have all the updates. 

To have everything working like a charm, the cost that you pay for it is worth it. In Bolivia, we don't have the best internet connection. Therefore, we have a local service with all the packages, repositories, etc. We manage them locally, and because we have a subscription, we can update them. So, we have local repositories with all the packages and other things to make it easy for us to update all the servers. Without the Red Hat subscription, we cannot update anything.

We were thinking of SUSE because it also has enterprise solutions. We decided on Red Hat because of OpenShift. This was the key thing for us. 

Red Hats' open-source approach was also a factor while choosing the solution because there is a law in Bolivia that is forcing all public institutions to migrate to open source. By 2023, all public institutions must run on open-source solutions.

You cannot compare it with anything that is in the market because there is nothing that does the same. Amazon is doing something similar, but it is still a different service. Everything that they give us surprises us and changes the way we are doing things.

It hasn't simplified adoption for non-Linux users because we have mostly deployed servers, and they are not visible to the users. Users are just using the applications, and they don't know what is going on in the background. They don't know if they are using Linux or something else. They are using Windows on the client, but on servers, they don't know what is running.

We aren't using bare metal for servers. Everything is virtualized and working just fine. We have VMware, OpenShift, etc. Everything is deployed on our own cloud, and everything is on our server.

We use the dashboard of OpenShift to monitor the whole infrastructure, but we also have two solutions that are not by Red Hat. One is Zabbix, and the other one is Pandora. Both of them are open source. The dashboard of OpenShift doesn't significantly affect the performance of existing applications, but it is helpful because it can send triggers. It has triggers to send alerts and things like that. It is not really resource-consuming. It is really good.

I would rate Red Hat Enterprise Linux (RHEL) a 10 out of 10.

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.

I use Red Hat Enterprise Linux as an operating system for government contracts. 

I like the flexibility Red Hat Enterprise Linux offers in terms of permissions. The patch management is much shorter and easier. Red Hat Enterprise Linux helps us move workloads between different clouds and data centers. It's pretty smooth and transparent. 

We use AMIs — machine images — for provisioning. The image builder is nice. It's a vertical Amazon machine image. They have each machine image, so you don't need to install anything. You can just copy the machine image. 

There's an operating system called EdgeOS, which is an edge operating system used by edge computing nodes in the cloud. If Red Hat Enterprise Linux had a version incorporating EdgeOS-type functions, that would be great. Otherwise, you have to learn a little bit of EdgeOS to work with those nodes.

We have used Red Hat Enterprise Linux for several years.

I rate Red Hat Enterprise Linux nine out of 10 for stability. 

I rate Red Hat Enterprise Linux nine out of 10 for scalability. 

I rate Red Hat support nine out of 10. 

Positive

Red Hat offers better support and stability. There are several others, including Windows, and Red Hat Enterprise Linux is a pretty stable standard operating system. 

I rate Red Hat Enterprise Linux nine out of 10 for ease of deployment and migration. Deploying an AMI is straightforward. We hardly had to do anything. It's pretty much automatic and uninterruptible. 

I wasn't involved in the licensing, but Red Hat Enterprise Linux's price should be reasonable if the government and others get it. 

I rate Red Hat Enterprise Linux 10 out of 10. It's the top of the line.

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 a Red Hat Enterprise Linux partner and provide host servers for various applications, including web applications and databases.

Red Hat Enterprise Linux's built-in security features simplify risk reduction and compliance maintenance, making them easy to use. We utilize SA Linux, a highly secure operating system. Its risk mitigation and compliance measures are effectively implemented due to the regular delivery of patches, updates, and bug fixes. This continuous maintenance enhances the stability of the system.

We are able to maintain compliance when it comes to the security regulations.

The level of portability succeeds in keeping our organization agile.

We used several platforms, but Red Hat provides us with a more uniform installation process, a more consistent platform, and easier system maintenance. Additionally, the Ansible playbooks are now simpler to manage due to the standardization of our platform. We quickly realized the benefits of adopting a single platform instead of using multiple platforms. This decision has streamlined our operations and simplified license management for our sales department. Additionally, the purchase process has become more straightforward.

We operate a hybrid IT infrastructure consisting of both on-premises and cloud servers. We have had positive experiences with Red Hat Enterprise Linux, which has enabled us to build and deploy applications with confidence and ensure their availability across physical, virtual, and cloud environments.

Red Hat Insights is a valuable tool for preventing emergencies caused by security vulnerabilities, non-compliant configurations, and unpatched systems. Although we haven't faced an emergency yet, we've noticed that the tool provides valuable advice and sometimes even playbooks to resolve security and stability issues. It's a powerful tool indeed.

Red Hat Insights provides us with vulnerability alerts and targeted guidance. All systems are stable and we have no crashes and no failouts.

Red Hat Enterprise Linux's most valuable attribute is its stability.

A targeted package tailored for small and medium-sized businesses can help increase business.

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

Red Hat Enterprise Linux is stable. We have been running the solution for years with no crashes.

Red Hat Enterprise Linux is scalable. We have not encountered any issues. Since we are virtualized, it is merely a matter of allocating virtual CPUs, virtual memory, and so on. The limits are very high, so we are not currently experiencing any constraints.

The technical support is good.

Positive

We switched from our previous solution to Red Hat Enterprise Linux because of the uniformity of the platform. It is also a larger organization that is well known.

The initial deployment is straightforward and well-documented. The deployment time is between 15 to 30 minutes.

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

From what I've seen of Red Hat Enterprise Linux, it's well-documented. There are comprehensive notes and documentation available. I've been using it recently, and I've found that all the information I need is readily available. If we can't find what we're looking for, our support organization is there to help.

We have a virtual environment and deploy the solution from a satellite.

Currently, we require two people for the maintenance of Red Hat Enterprise Linux.

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.