Red Hat Enterprise Linux (RHEL) Reviews

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.

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 for RHEL is running our front-end web servers. When you visit our site, all of the front-end servers are Red Hat. The databases that are hosted are Oracle and they predominantly sit on Red Hat 7. We're trying to migrate those to version 8.

We also use it for BI.

We have a digital footprint in Azure and AWS, as well as on-premises. Things for us are very fluid. We're always changing and adapting to our environment, based on what the needs of our faculty and students are.

The experience depends on the user and what it is that they are doing. If somebody is a Windows user, they're not comfortable with Linux, even if it has a GUI. The graphic user interface can be off-putting to users that are familiar with Mac or Windows. It's not as fast, snappy, and showy as the Windows or Apple graphical user interface. So, those types of users for office production, probably, will not be happy with the Red Hat product line.

If on the other hand, you're a developer or you're a database administrator (DBA), it is different. My experience with my developers and my DBA is that they love Linux. It's easy for them to use. It's easy for them to deploy things like Oracle databases and web servers. Continuous development integration tools like Maven or Tomcat or any of those frameworks are already put in place.

For all of the backend tools that do the work to build the infrastructure, Red Hat really does a good job to make it easy to deploy those consistently, securely, and upgrade them in the same way. There are a lot of pluses for the developers, the DBAs, and the like. But, if you're a regular office user, Red Hat is probably not the tool or the OS that you want to use.

When using RHEL for tracking or monitoring, they do a very good job with respect to the impact on the performance of existing applications. The nice thing about Red Hat is you can get very granular with your logging. We do log aggregation, we use Elasticsearch, and we use Filebeat. These things are part of our log aggregation applications and services that run on the backend of our Red Hat boxes, and it does a very good job of that. We also add bash logging into our hardened Linux deployments, so we see everything. We want to monitor everything, and Red Hat does a really good job with that.

RHEL has given us the opportunity to accelerate the deployment of our cloud-based workloads, although because my organization is a very small college, and we don't have a lot of funds, we can't afford to have all of our workloads in the cloud. It's actually cheaper for us to run most of our applications and servers on-premises.

The workloads that we have in the cloud are typically mission-critical, like student transcripts and stuff like that. These are the types of things that we need to have backups of, which is something that Azure does with Red Hat very well. We are moving in the direction of using Red Hat in the cloud, with the caveat that we deploy only as we can afford it.

With respect to disaster recovery, Azure and Red Hat are probably one of the best pairings that you can get. It provides a lot of redundancy, it's easy to deploy, and the server support is excellent with Azure. There is also good logging, so if you do have an issue you can troubleshoot rather quickly and resolve the problem.

The integration with other Red Hat products, such as Satellite, is excellent and I haven't had any issues with it at all. Everything works very well together with all of the products that we use. For example, Ansible works very well with Satellite. We also used Salt at one time, and we used Puppet. We've moved away from those and just focused on using Ansible. All of the tools that we've used work very well with Rad Hat. The product is mature enough that there's enough support for it from all of the other vendors that run on the Red Hat platform.

There are lots of good features in this product. Because I am a system admin, I don't tend to use the GUI or end-user features. Everything that I do is executed from the command line, and this includes features like monitoring tools, such as netstat or iostat. These are the tools that are built into RHEL. Their toolboxes are good but I wouldn't consider them a great feature because there are things that they still need to work on.

The feature that I like the most is that we can integrate it easily with our existing infrastructure. We found that it is much easier to deploy RHEL in our environment compared to a competing distribution like Ubuntu. This is because we also use RHEL Satellite, which is the patching and lifecycle management application that binds all of our RHELs and allows us to push out new stuff.

Satellite is an important feature because it helps to speed up deployment. Satellite is Red Hat's solution to Windows, where the Windows equivalent would be Server Center Control Manager (SCCM), which is now Intune. Satellite is the lifecycle management application for deploying, maintaining, and upgrading your Red Hat systems, and it does a very good job of that. Satellite works in tandem with Red Hat, as you use it to deploy your server.

The main point is that Satellite makes it quick and easy to deploy, and it is also easy to automate the process. I'm the only Linux person at my organization, with the rest of the people working with Windows. Using Satellite, a Windows end-user can deploy a Red Hat server without any Linux experience.

The security updates are done very well, so I feel confident that I'm not going to get hit with ransomware or a similar problem. Their security patches are pretty up to date. Also, it's rather easy to harden a Red Hat deployment because they provide tools to help you do that.

Red Hat gives us the ability to run multiple versions of applications on a single operating system, although we only use this functionality for Java. Even then, it's specific to the underlying applications. For example, Oracle uses Java on the backend. Also, we have multiple versions of Java on some of our web servers and it does a good job.

The biggest thing that is crushing RHEL is documentation. Their documentation is haphazard at best. The man pages that you can use locally are pretty good, they've been fleshed out pretty well, but the documentation from Red Hat itself really needs somebody to go through it and review it.

The only real negative that I have with Red Hat is that you can tell that when you look at the documentation, they cut and paste documentation from the previous version. Because they update it that way, what happens is that there's nobody doing Q&A. For example, in Red Hat 7 and Red Hat 8, they changed the way they do deployments. Instead of using YUM, you use DNF but when you read the documentation for Red Hat 8, they intermix the two. This means that if you're a new Linux user, it's very difficult to distinguish between the two commands. The fact of the matter is that one is built on top of the other. DNF is backward compatible on top of YUM, and that can cause confusion with users and system administrators. However, it wouldn't be an issue if there was good documentation.

My job is pretty easy, but the documentation would really help me be able to communicate the things that I do to the rest of my team. They're all Windows people and when I go to the Red Hat documentation and tell them that we're migrating to this and we're using this tool, but the documentation is horrible, I get laughed at.

By comparison, Microsoft has its own problems with documentation, but it's a little bit more organized and it's definitely fleshed out a lot better. I commend Microsoft for its documentation. Red Hat may be the better product for the things that we do in our environment, but Microsoft has better documentation.

I have been working with Red Hat Enterprise Linux for the past four years.

This is a very stable product.

In terms of scalability, you can't beat it. It's easy for me to scale up and down, especially with Satellite. I can push out 10, 100, of the same servers for the same configuration and set up with the push of a button.

On the cloud side, Azure also allows us to scale very nicely. This means that we can scale locally if we need to because we use Hyper-V for our VM management and we can spin up 10, 15, or however many servers we need, relatively easy with the push of a button, and you can do the same thing in Azure. We haven't done that in AWS.

Most of the servers that we spin up are proxies. We use a product called HAProxy, and we can deploy those proxies as needed. There are also busy periods where we need to scale. For example, when it's the time of year for students to register for classes, we'll see an increase. 

Another thing that is nice is that Azure will scale as we see more users come online. It will automatically spin up Red Hat boxes to accommodate, and then it'll bring them back down when that surge is over.

Overall, scalability is very nice, either in the cloud or on-premises. As far as setup and configuration, you can make sure that it's consistent across the board, no matter where it is deployed.

I would rate their frontline support, where I submit a ticket, a seven or eight out of ten.

In terms of support that is available through their documentation, I would rate it a three out of ten.

Before I started working for the organization I work for now, I used a product called the FOG Project. At the time, we used Ubuntu Linux. FOG was the equivalent to Satellite and Ubuntu is the equivalent to standard Red Hat.

Comparing the two are apples and oranges. The FOG Project is not as mature as Satellite; it doesn't have the bells and whistles that Satellite does. In general, their lifecycle management tools cannot be compared. Satellite outperforms the FOG project, it's easier to deploy and easier to use.

When comparing Ubuntu and Red Hat, the big difference is that the releases for Red Hat are more stable. They do lag a little behind Ubuntu, as Ubuntu is more bleeding edge. This means that they're pushing out updates a little bit faster, but they're not clean in the sense that they may push out a patch, but then five days later, they have to push out a patch to patch the patch. This is in contrast to Red Hat, which is a little bit more consistent and a little bit more stable. What it comes down to is that Red Hat is much more stable than Ubuntu in terms of patches, updates, and upgrades.

Those are the key differences for somebody who manages that infrastructure. You want something that's easy to diagnose, troubleshoot, and put out solutions. Ubuntu may push out a patch or an update that's so bleeding edge or so out there that vendors haven't had time to come up with solutions on their own, so if it's a driver issue or something like that, with Ubuntu, you may have to wait around as a user for those kinds of solutions.

With Red Hat, they make sure that when the product goes out, that there is some Q&A, and they've done some testing. They make sure that there's compatibility with other products that depend on that particular feature, functionality, or service.

RHEL is very easy to configure and deploy.

When we're talking about RHEL in the cloud, Azure is probably the better platform for RHEL. AWS has some licensing issues. The business end of using RHEL on AWS is not as mature or fleshed out as it is on Azure.

Incidentally, I'm not a big fan of Azure. Rather, I have most of my experience in AWS, but Azure deploys Red Hat without issue. We don't have to worry about licensing and connecting things. Everything is already bound to Azure AD, and that makes it really nice because on-premises, we have to do that manually.

For the on-premises deployment, part of the deployment package requires that we add our Red Hat servers to our local AD. But in Azure, it just does everything for you all within one PowerShell command. Ultimately, deploying Red Hat in Azure is much easier than deploying it either on-premises or on AWS.

We have seen a return on our investment. Our organization is probably going to stick with Red Hat because the licensing fees are low enough to offset the maintenance and support cost of that OS.

Pricing is always a critical factor for all IT departments. The cost of doing business is part of the nature of the job. If you're going to buy a bunch of Dell servers, for example, you have to take into consideration not just the licensing, but the hardware support and other things. The licensing with Red Hat is on par with other organizations like Microsoft.

We buy our licensing in bulk, meaning we buy perhaps 1,500 licenses at a time. They changed their licensing structure over the last couple of years. It used to be per system, whereas now, it's all or nothing. We don't have a subscription, as they used to offer, because they moved away from that. We have a site license, which gives us a certain number of servers, perhaps 25,000, for the type of license that we have. That works really well for us.

The way our structure is set up is that we just buy it by the tier system that they have, so if you have so many servers then you buy that tier and then you get so many licenses as part of that tier or enterprise package.

There are additional fees for using other Red Hat tools, such as Ansible Tower. We use Satellite, and it uses Ansible on the backend. However, we use the vanilla Ansible out of the box, rather than the official Red Hat Ansible Tower, simply because we can't afford the licensing for it. Satellite bundles everything together nicely in their suite of tools but we have moved away from that because of the additional cost.

This is one of the downsides to any operating system, not just Red Hat. Windows, for example, is the same way. They try to bill every organization for every license that they can by adding on different suites of tools that they charge for. A lot of organizations, especially the smaller ones, simply can't afford it, so they create workarounds instead. In our case, Ansible is freely available and we can use it without having to pay the fees for Red Hat's Ansible.

The nice thing though, is that they give you the choice. Red Hat doesn't force you to buy the entire product. They still have Ansible entwined with their Satellite product. The point is that if you want the additional features and functionality then you have to buy their Ansible Tower product, but you can still use the basic product regardless.

The fact that RHEL is open-source was a factor in us implementing it. This is an interesting time for Red Hat. The great thing about Red Hat for us was that we could use Red Hat and then we could use their free, commercial version, which is CentOS. It stands for Community Enterprise OS. Unfortunately, they are no longer going to push out CentOS and I think that 8.4 is the latest version of their free Red Hat distribution.

When we first went to Red Hat, in all the organizations I've ever worked at, being able to test things was one of the key factors. We could spin up a CentOS, implement a proof of concept and do some testing before we actually went to use RHEL, which is a licensed version. The real plus was that we could do testing and we could do all these things on the free version without having to eat up a license to do a proof of concept before we actually invested money moving in that direction, using that particular product or service.

Now that this ability has gone away, we are going to see how that pans out. I think Rocky Linux, they're hoping that that's going to be the next CentOS or free Red Hat. We'll see if that pans out or not but right now, it's a scary time for people that are dependent on CentOS for their free development environments, where we can just spin that up and play around. Right now, we're looking at how we're going to resolve that.

It may be that we have to eat up a license so that we can spin up a machine that we just want to do a proof of concept. This is something that we don't know yet. I don't have an answer because we simply don't have enough data to make an assessment on that.

Everything considered, having a free commercial version available, in addition to the paid product, is a big lure for us. They worked really well in tandem.

We have approximately 14 servers running Red Hat 6 but we used Red Hat 6 all the way to Red Hat 8.

The AppStream feature is something that we have tried but on a very limited scale. We have had mixed results with it, although it looks promising. At this point, I can't say whether it is a good feature or not.

My advice for anybody considering Red Hat depends on the role of the person that is making the decision. If they're an end-user or their organization is using office productivity software, then they're probably not going to want to use it for the backend. This is because there are not a lot of users that are using Red Hat as their office productivity operating system.

If on the other hand, you're somebody that's looking for servers that just need what they call five nines or high availability, Red Hat is your solution for that. That's what I would say to anybody, any technical person that I've talked to, if you can afford it, definitely get Red Hat for your web development. Your web servers should be either Apache, or NGINX, which is their web server stuff.

Red Hat should also be used to host an Oracle database. We found that that works really well and is very competitive with Microsoft's SQL server. It's about the same cost; the Red Hat product is actually a little cheaper than Microsoft's SQL product.

Considering the cost, ease of deployment, and ease of use, Red Hat is the better product for your main infrastructure. For things that just have to be up and running, Red Hat is the product that you want to use.

I can't be strong enough in my opinion that Red Hat does what it does very well for the mundane tasks of infrastructure. For instance, when it comes to web servers, no other OS does a better job than Red Hat for web servers or databases. Similarly, it does a very good job for proxies. For things that just need to run and have very little human interaction, Red Hat's your solution. If you're looking for something that's for an office, such as for accounting, then Red Hat is not the solution to choose.

I would rate this solution an eight out of ten.

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.

We use Red Hat Enterprise Linux mostly for development.

We use Red Hat Enterprise Linux with Git apps in our closed environment to develop and run scenarios.

Red Hat Enterprise Linux's documentation could be improved. Sometimes when you call up support to have that Red Hat answer, they send you back a Reddit or Google link. I can Google or go to Reddit, but I want an answer from Red Hat.

I have been using Red Hat Enterprise Linux since it started back in the 1980s.

I rate Red Hat Enterprise Linux a ten out of ten for stability.

I rate Red Hat Enterprise Linux a ten out of ten for scalability.

I rarely call Red Hat Enterprise Linux's support, but when I do, they send me a Google link.

Neutral

Since I've been deploying Red Hat Enterprise Linux for so long, it's not complex for me. Once we configure our kick start, we power up a new system, attach it, and it builds it.

We implemented Red Hat Enterprise Linux directly through Red Hat.

We have seen a return on investment with Red Hat Enterprise Linux concerning the ability to develop what we need, what we do, and our scenarios. The solution saves us man-hours, and man-hours equals money.

We cannot use Red Hat Enterprise Linux on the cloud because I work as a contractor for the government, and all our development is in a classified area where we can't touch the internet at all.

In the last quarter, Red Hat Enterprise Linux products like Satellite Server and OpenShift stood out because of their ease of administration. I do system administration. When my customers need something, assisting them with these products is easier than giving a long configuration of YAML.

I like Red Hat Enterprise Linux's built-in security features. We use their SCAP features when we do our kickstart and build it.

We were using Docker, and the Docker swarm was trying to get all the containment. We're now switching to Podman and getting our developers to learn that more so we can give them the ability to kick off containers.

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