Red Hat Enterprise Linux (RHEL) Reviews

Our company uses one of the solution's varieties, mostly CentOS. We are restructuring and moving to the licensed version of RHEL and its derivatives. 

We use both RHEL 7 and 8 mostly in the cloud but also have a small data center where the solution is used on bare metal. Our team does a lot of AIML work where we set up instances to run simulations. 

We are moving a bit into Redshift because we do not have many staff members with containerization or Kubernetes experience. 

We run most things on the solution and its impact has been huge. We do have a few items on Ubuntu but question its use. Conceptually, Ubuntu is for amateurs and RHEL and CentOS are for professional organizations with hardened security. 

The YUM repository is valuable. We are in an interesting situation because we cannot have access to direct YUM or browser repositories so we have to copy to a Nexus server and pull from there. From what we have seen, pretty much everything is available right there. 

The solution's use of Kubernetes as an internal or core process on the system is brilliant. You eventually get to Kubernetes whether via Redshift or other tools and do not have to worry about your hardware because you deploy and push to the infrastructure without worry. 

The Cockpit makes it very easy to maintain systems because you do not have the overhead of running gooey but still have the interface. I am a Linux person and had issues with Windows because they required gooey on servers when it was not necessarily needed. 

The solution is moving away from CentOS and there are growing pains from the customer's perspective. It was purchased by IBM and they are for profit which everyone understands. There is a huge shake up right now because customers who run CentOS do not know what to do with all their systems. One of the reasons CentOS is used for government offices is its security feature that does not change because it occurs after route. The solution placed CentOS in the middle so government customers do not trust it. The way the rollout occurred caused a lot of mistrust with Red Hat. 

The SELinux is great but the Amazon security features cause issues. For example, we run RHEL and CentOS on AWS but they control the cloud and do not give us access to security features. We have to go through multiple layers to deploy an instance. Something that could be controlled with a firewall or blocking ports is now controlled by security groups inside AWS that we cannot access. 

I am newer to the solution but our company has been using it for a long time. 

I previously worked with an Intel customer who used a lot of CentOS, so I am aware in that sense. I am very familiar with the YAM and DNF. I have even played a bit with Rocky which is not specific to the solution. 

My work in systems and software supports one of our teams. 

Technical support staff are personable and quick to get to problems. Support is better than other vendors and I rate it a ten out of ten. 

I used to work for a government organization that was heavily into AWS. One of the reasons they embraced open source was because Oracle was too expensive. They put everything into AWS rather than open source, so they will soon be in the exact same position where everything is proprietary. 

The solution is easy to set up but sometimes there are issues with custom software deployments. For example, we want to use Ansible in RHEL 8 but the software is only supported in RHEL 7. We question whether we should install an old version of Python to get things to run. 

The solution is pretty easy to troubleshoot. 

Our organization is huge but I handle the setup for instances in our small data center.

I do not deal with money, but I see an ROI in terms of the engineers' skills because they can reapply them to multiple RHELs and incidents. 

The solution is moving away from its open source roots and licensing is a little bit of an issue. 

We use Ubuntu, but not much. 

Primarily, we are dedicated to RHEL and CentOS to the point that we do not see Windows as a viable server option. Microsoft's cloud is getting traction but it only makes sense if you have a solution meant for Windows. 

We also use Redshift and Cockpit. There is consistency across products so they are backward compatible with familiar operations. For example, you could use RHEL 8, YUM, or DNF because the syntaxes are identical.  

The solution is very into Ansible and we are trying to drive everything to it.

Look at the security features of the solution and compare them with other options. Open source is great, but at the end of the day, you need someone supporting the product. Another option is to just listen to groups that write on the internet, but you have to decide if you trust that along with their adversaries. 

Government offices have to worry about adversaries from other countries because the code they use is unclear. The idea of open source is to be able to evaluate the code but it is not clear if anyone actually reviews it. 

I rate the solution a ten out of ten. 

We provide web servers and support for websites for the government, and they all run on the Red Hat Linux operating system.

It has had a very positive influence on our organization's management and efficiency. We couldn't live without it. We just could not.

It's easy to troubleshoot with RHEL. We're able to easily pull log files from servers, analyze them quickly and efficiently, and resolve matters.

They provide good notices on updates and fix packs that need to be applied. We do monthly updates and fix packs. Based on what their requirements are or what their messages are regarding updates, we're there. We do them quickly every month.

I like its user-friendliness for the admins administering the servers and the ease of doing fix packs on the servers and upgrades with the Red Hat software. It saves time and cost because we don't need to have expensive hires to do the work. We can do it ourselves a lot of times. It's a pretty straightforward, easy-to-learn, and user-friendly operating system.

Support for older versions of the operating system could be improved. If people can't afford to upgrade, or if they have servers that are outdated, they need to be able to provide back-field support for those.

We have been using it for at least 15 years. I've been with this outfit for 15 years, and I have been using it for 15 years.

As far as I know, we're just using Red Hat Linux. That's it. We don't use any other product of Red Hat. We do use IBM WebSphere, but that's totally different. Red Hat is our preferred one.

It's very stable. We don't have any issues with our servers crashing. If you scale your servers properly with enough RAM and resources, the operating system is almost up 100%. It's high availability.

It's very good. They provide notices on an as-needed basis. They're easy to get in touch with. They provide good customer support for our servers. Our hosting center uses them exclusively. I would rate them a nine out of ten.

Positive

It was already existing when I joined. I worked with the infrastructure group to maintain and apply fix packs and updates to the Red Hat software.

It does require maintenance. It requires doing fix packs and upgrades. There are some upgrades that are scheduled by Red Hat. It's not maintenance-free.

I would advise looking at some of the other operating systems out there and determining what your needs are in terms of if you're going to be using Linux, or if you're going to be using Microsoft. For Linux, it's definitely preferred, but just do your research and do your homework. I can't say enough good things about it.

I would rate it a nine out of ten.

It's what we run our primary mission systems on. Our office automation runs on Microsoft, which includes Word, email, etc. For everything that we present to the customers through the agency, the backend is an RHEL platform.

Through the various tools that we've utilized, RHEL was able to help improve our security posture. We run a very tight ship.

We use Satellite to do patch management and limited repository so that we don't have folks going out to the internet to get the repos. You have to get the repos through our Satellite system. We also do patches through that. We use Ansible for our automation to build boxes, to install all the security patches on them, and to run the vulnerability scan against them. It initiates that. Also, implementing IdM on them is done through Ansible. So, we use Ansible quite a bit, and we're just starting with OpenShift.

One benefit of using multiple Red Hat products is compatibility. Compatibility is the most important. We haven't had an issue where the tool doesn't understand the OS or doesn't understand the platform. Ansible written for Red Hat works perfectly. It understands the plugins and satellites, and it's having one ecosystem where it also gives one phone call. If there's a problem, we call Red Hat. That has been very handy.

RHEL’s built-in security features and security profiles are very good for reducing risk and maintaining compliance, but as a government agency, we have to use other baselines. CIS baseline is what we primarily rely on. We also put in a little bit of DISA as a baseline, but they're standard out-of-the-box solutions. It's pretty good. It just has to be tweaked slightly to get it to the level we have to run at.

It's relatively easy to troubleshoot using RHEL. Sometimes, the troubleshooting can take quite a bit of work, but it's an easily understandable OS. If you understand the basic key principles, you can pretty much work it out.

We're very happy with the amount of security customization we've been able to do with RHEL. The fact that Red Hat is really on top of security issues is also valuable. We get daily emails from Red Hat letting us know of possible issues and fixes, which is incredibly helpful for us.

Other than that, we use it as our primary DNS. So, DNS is an important piece of it. 

Compatibility is also extremely important. We get the ability to run as many applications on it. They are widely supported.

There are some things that we've seen from RHEL that have given us a little bit of consternation. Their IdM product could be improved greatly. It would be great if they had some type of application built in that would let you do whitelisting for applications. On the government side, for zero trust, that's becoming very important. We're currently using a third-party solution, and it's tough to get it to match up because anytime the kernel changes, you have to match the software to the kernel. If we get a critical vulnerability on a kernel, we have to roll out the new kernel but then our third-party software isn't cooperating, and it starts breaking down the system. So, it would be great if Red Hat could integrate that type of functionality into the product so that when a new kernel comes out, it includes the updated software to do whitelisting and blacklisting of applications and processes.

At the agency, we have been using it for about 10 years. For me personally, it has been about six years.

It has been relatively stable. The only time we see stability issues is when we introduce new third-party products. We have some mandates as a government agency to do some endpoint security stuff and integrating that in has caused us a few stability issues, but that's not so much the fault of Red Hat. It's a quagmire of the chicken and the egg. You have to run a certain kernel, but that kernel is not compatible with the other software that you are forced to run. So, we've artificially created stability issues.

They eventually work out or work themselves out. When the vendors get on board and update their products to match the kernel, then everything tends to function smoothly at that point until we introduce another hiccup. We're constantly throwing hurdles, but we also have a very good system for bringing stuff back to life after it's dead, and we've done it enough that we're pretty timely. We can get one of our servers up in about 10 minutes.

It has been relatively scalable. We don't have any super large deployments, but we've had some scaling of specific applications, which has worked out great. We're integrating it more into Ansible and using our virtual hypervisor platform to recognize times when it needs to scale, and when we expect a large deluge of customers coming into our website, we have to have the backend expand. We've been doing that manually up to this point, but we're looking forward to being able to automate that.

We wanted an enterprise platform that was going to be supported. So, support from the vendor has been very important to us, and Red Hat has always provided that. When IBM took over Red Hat, we were very afraid that it was going to change our relationship with Red Hat, but it worked out very well. We've got a great sales team that has helped us, and they've always been able to get us the technical support we need when we run into an issue.

Until we got our new salesperson, I would have rated them a two out of five. Now that we've gotten our new sales team, we've gotten the right people in the right places, it's definitely a five out of five. We had a salesperson who was more focused on larger agencies, and we're a relatively small agency. So, we weren't getting the amount of focus that we needed, but that changed when our Director and our CIO engaged Red Hat's Enterprise Management. They were able to get us someone who could be more focused on smaller agencies and be a lot more helpful, and he has absolutely done that.

Positive

I was involved in the deployment or setup of RHEL to a degree, but it was mostly during our life cycle refreshes when we moved from RHEL 6 to RHEL 7 to RHEL 8. And now, we're looking at RHEL 9. 

On the backend development of the base image, I'm part of the team that puts together the base design, and then we put the steps into our repository so that we can rebuild the images easier. Right now, it's a manual process. We want to get to the point where we have all of the changes documented in a GitHub solution or something where we can make a change, push a button and have it implement those changes in there by using a script or something else. I'm mostly the one yelling to the Linux developers to get their stuff done because they have a tendency to run multiple instances while they're transitioning. They'll run an RHEL 6 box, an RHEL 7 box, and an RHEL 8 box at the same time when they have to get off of RHEL 6 and RHEL 7. So, I'm more of the management yelling at them to get this stuff done.

I would advise making sure you get a good support contract and you have a very good salesperson to work with.

In terms of RHEL's effect on our organization's management and efficiency, it can always be improved, but we probably are a three out of five on efficiency. As we move into OpenShift and get a lot more automation working, we will move slowly to the five, but that's not the fault of Red Hat. That's the fault of our organization having limited resources, and Red Hat is helping to provide the tools to get us to the next level.

Given that we started running everything on Microsoft, Red Hat is a lot more flexible in giving us the ability to span out specifically as we move into containers. It's going to give us the ability to stand up a lot more resiliency. When we're getting a heavy load, we can expand. Even currently, we have the ability to expand slightly but moving into containers will give us even more capability. We've chosen Red Hat as our platform. Red Hat has done well enough for us, and that's the platform that we're moving to with containers.

At this point, I would rate it an eight out of ten because there's always room for improvement. I don't feel that there's a perfect OS. I would even rate Windows as a seven. There's definitely room for improvement, and with Red Hat being one of the larger targets out there for hackers and people, there are always issues coming up.

I'm using Red Hat as an OI solution with some Oracle databases and an FTB server on top of it. I am not using containers in Red Hat. It's solely serving as an OS with direct applications installed on it. We have a few thousand users benefiting from Red Hat indirectly, but only 10 to 20 people work directly with it. I only use Red Hat in one location right now. Previously, I had it deployed in a cluster. 

The most important thing for any organization is stability and uptime for the application and the environment. Red Hat provides us with stability and uptime, and it gives us all the tools we need to integrate with our other solutions. 

It's also a suitable environment for applying security certificates. You can perform all the requirements on Red Hat. For example, you can do everything you need to comply with BCI, ISO, or any other certificate. 

The most valuable thing about Red Hat is its stability, uptime, and support for various hardware vendors. Linux servers, in general, are relatively secure and they are more secure than Windows and other products. 

Red Hat provides additional tools to customize your environment and harden your OS. For example, you can apply security patches and use benchmarks. You can do everything in Red Hat, so you can always have a highly secure environment. The interface is pretty good. Our engineers like the PLI interface.

I've been using Red Hat for around 10 years. 

Red Hat is as stable as you want it to be. We periodically have some bugs, but we can resolve these issues quickly. 

Red Hat can be scalable, especially if you are using it for virtualization. For example, KVM is easy to implement and scale up. You only need to add more nodes to scale as much as you want.

I rate Red Hat support nine out of ten. It's nearly perfect. Red Hat support has one of the best teams I've dealt with. 

Positive

I've used some open-source environments like CentOS and some other solutions like Solaris and HBOX. We switched to Red Hat because it's easier to deploy and manage.

Setting up Red Hat is straightforward if you're doing a basic installation. They have a beautiful installer that handles everything. For a more advanced deployment, you may need to go through some more complicated steps to customize it for everyone's best practices. 

You only need one person to handle the installation, which takes anywhere from a few minutes to an hour, depending on the installation. If you install Red Hat correctly based on your requirements, you don't need to perform any maintenance. You might need to patch, upgrade, add resources or harden the OS. When discussing security, you always need to follow up on patching and security hardening.

The cost could be lower. Red Hat is considered a costly solution. It can be expensive if you want all the features in the license. A cheaper license would make Red Hat more accessible to a broader range of users. It's reasonable given the features and performance, but a lower price would encourage more people to adopt it.

We looked at HBOX servers, but they are far more expensive than Red Hat. Red Hat is more optimal in terms of cost versus performance and stability than other solutions like Solaris and HBOX.

I rate Red Hat Enterprise Linux nine out of ten. It's an excellent solution. Go for Red Hat If you want stability at a reasonable cost. It's the best.

I am primarily doing developer enablement for users of Red Hat-based software stacks. Most of my experience for the last five years will be in the context of AWS and Azure. As my customers are primarily cloud-based, they are primarily using the Red Hat repositories hosted with Amazon and Azure.

My customers are primarily DoD, so they are using EL7. We are trying to get them to move in the direction of EL8, but it is a slog.

As an industry recognized platform, and the fact that Red Hat goes to great lengths to get their stuff security accredited, it makes it a lot easier for me to get applications put into production since I can point my customer security people at the work that Red Hat has done upstream. Then, all I have to do is account for the deltas associated with the specific deployment in their environment. It greatly reduces the workload when you can get it down to just deltas.

Automation is the most valuable feature. I don't like having to solve a problem more than once. If I can just whip up some code to take care of deploying something, responding to something, etc., then that is what I prefer. It is a lot easier out-of-the-box to do than it is with Windows. With Windows, there is always the process of bootstrapping into being able to have the automation framework available, then making the automation framework work.

In the AWS space, the cloud network is packaged. Tools, such as Ansible, Puppet, and SaltStack, are all easily found and installed. That is quite helpful.

The integrated solution approach makes it a lot easier to deliver things on an infrastructure as code basis. So, if customers need something deployed, I can just do a set of automation for them. This gives them an easy button to take care of the rest of their solution, whether that be deployment or lifecycle maintenance of a deployment.

I use their tracing and monitoring tools on an as needed basis.

It is great for the stuff that Red Hat either owns outright or is the lead on the upstream product. When it comes to third-party tools, it can be a little iffy. Some of the database solutions and data governance solutions that I have had to implement on Red Hat have not been fun.

I would mostly like to see improvement around corporate messaging. When Red Hat 8 came out, and Red Hat decided to change, it inverted the relationship between Red Hat and CentOS. This caused my customers who had a CentOS to RHEL development to production workflow quite a bit of heartburn that several of them are still working out. A lot of that probably could have been avoided through better messaging. 

I have been using it for a couple of decades.

This is a double-edged sword. From a stability standpoint, it is great. From a facilitating development, at least up through Red Hat 7, it was problematic. If you wanted the latest and greatest version of Python, Java, or any given development language that your developer community wanted to use, then your choices were package it yourself or use SCL. Packaging it yourself was flexible, but then it caused auditability problems for your information assurance folks. Going the SCL route was good, but activating it in a way that developers were comfortable with was problematic. It looks like the AppStream capability in EL8 will ease some of that. However, I haven't had enough customers using EL8 yet to verify whether what seems more usable to me will be more usable for them.

So far, I haven't found anything that inhibits scalability. The only thing that I run into is probably more a side effect of how my customers use things than Red Hat itself, in so much as my customers tend to prefer to implement things in a way where it is a bit of a heavier weight than they absolutely need. This slows down the speed at which one can deploy. However, this is more of a customer issue than a Red Hat issue.

RHEL is the basis of all my customers' cloud and container solutions. 

I have worked with Red Hat technical support minimally. Most of my customers operate in the DoD and the intelligence community. Much of their stuff isn't really able to be supported because you can't export logs or anything like that. At best, things are indirect. The things that I tend to seek assistance for are fairly edge case problems. Then, it is a case of needing to work through the process to get to the backline engineers. Every time I do that, it is not a quick process.

When I get to the part of the support system that I actually need to be at, then I would probably rate support as 10 out of 10. Getting to that point in the support resources is about five out of 10. Overall, I would rate it as six or seven out of 10.

Neutral

I automate everything. I write the automation that creates the VM templates. Once my automation is done, there is really nothing to set up.

Operating in the cloud space, we typically point our customers to pay-as-you-go licensing, which comes through the various cloud providers repository services.

I have experience with probably two dozen different Unix-type operating systems. However, 2010 would have been the last time I touched something other than Linux and 90% of that would be Red Hat.

For anyone who is doing physical or on-premises virtual, I would probably point them at Satellite, and if they can afford it, as an enterprise license. This is just so that they don't have to deal with picky unit licensing concerns. However, for people who are fully cloudy, I would tend to push them more towards using the RHEL solution.

Some of my customers use OpenShift, many of my customers use Ansible, and a lot of them use a local Docker and Podman. The ones that actually run within Red Hat integrate just fine. The ones that Red Hat runs on top of, those are a little more difficult to speak to. Running Docker inside of RHEL is easy. It is much better on EL8 than it is on EL7.

I like it enough that I use it as my own operating system for my personal web and mail server. So, I would rate it as eight or nine out of 10. The primary hits against it are that if you want to do anything bleeding edge, the pursuit of stability works counter to that.

We have warehouse management systems (WMSs) where we run Oracle as our database. The app tier is basically Java. We are using a vendor-supplied Java, and the application itself is managed by the vendor. There are just one-offs here and there, such as utility boxes, but the majority is Oracle and the application that connects to Oracle.

On larger systems, like HANA, we have it deployed physically. On everything else, we have deployed it in a VMware environment. It is all on-premises. While there is some cloud, that is being done by contractors. 

We are on versions 6 through 8. As soon as version 9 gets released to GA, I am going to start working on getting that image ready. Currently, about half our images are on version 8, two-fifths are on version 6, and then version 7 is squeezed in-between.

The solution provides features that help me tweak or configure the operating system for optimal use, such as Insights Client, which I have used quite a bit to help me.

Our users are removed from the environment. They don't really know that they are running on RHEL. There have been very few complaints about speeds, application, or stability on RHEL platforms. Whereas, on Windows platforms, there are a lot of complaints.

Satellite 6.10 and RHEL integrate with each other perfectly. This integrated approach enables me to be a single person managing my images since it does a lot of the manual labor that I used to do, such as building patches, doing system maintenance, and keeping systems consistent. It does all that stuff for me. So, it has offloaded those responsibilities, giving me more work-life balance.

It is a bit on the pricier side. However, due to the stability and support that they provide to my management and me, we really don't see a reason to choose another way to go. Red Hat offers excellent support in a sphere where it is difficult to find good support.

I have been using RHEL since 2013.

It is a good operating system. It is very stable. It does not take a lot of maintenance. You set it up well and it runs. To give some perspective, we also have Windows admins. That team is about six people and growing. They manage twice as many servers as I manage, keeping them busy all the time. Whereas, I pretty much have a life; the work-life balance is very good.

RHEL is very stable. You build an image and deploy it, then it runs.

As far as the operating system contributing to reliability, it is very stable and has low maintenance. It keeps running.

We found that two of our outages in the past eight years were related to the operating system. All our other outages were related to the application and the use of the application.

I don't find the solution’s tracing and monitoring tools impact performance at all.

We can scale out. When we need more machines, we just build more machines. That is not a problem. We don't do the scale ups or any of the other scaling that is out there. That is partially because of the way our applications work. You need to scale according to the application. If the application requires new nodes, we just spin up another node and it is no problem. I could run 10,000 images, and it is not a problem.

Because we buy companies, we will probably continue to increase the usage of RHEL. I don't think that will be a problem because it is so stable. We are running about 200 images right now and about 60% of those are in production. I can't see it shrinking, but I can see it growing.

I like the fact that they really dig into things and then provide answers. As the single Linux guy, I kind of need that second admin next to me sometimes to say, "Hey, what about this?" and I am able to do that through the portal. I get my questions answered and trouble tickets resolved.

The technical support is superior to many vendors with whom we interact. They pay attention. Rarely will I run into a support person who doesn't seem to know what they are doing, then it doesn't take very long to get the issue escalated to somebody else. Out of a hundred cases, I have probably escalated three times. I would rate the support as 10 out of 10.

Positive

I came from a Unix background. I was on HP-UX on OSS and AIX. So, the transition to Linux was very simple. I am a command line person, so I wasn't scared. I just moved into it and found it to be very attractive. In fact, I don't run GUIs on any of my Linux boxes.

The biggest benefit for me, coming out of the Unix arena, was that it matched Unix very closely. So, I am able to draw on my Unix experience and use that in the RHEL environment. There is almost a non-existent learning curve in my situation.

The initial setup of RHEL is about 10 times easier than Windows. It is literally just click, click, bang. It just installs. If you have a problem with the install, you just reinstall it. It takes very little time to install, about 10 minutes. As a base image, it is very easy to set up. Then, you have post tweaks that you need to do, and I have scripts for that. Since I can script it all, I just run another command, then boom and it is all done.

For my implementation strategy, I build the gold image, which is basically just going through the CD and making my selections for a base image. Then, I freeze that image, which is on VMware, and run my scripts. My scripts basically set up logs for auditing. Whether we are going to ship logs or keep logs locally, it sets up the basic users. For instance, it will set up my account with pseudo access so I can do the remainder of the work using my account with pseudo access. It sets up tracing, the host name, IP addresses, and ESXi host files. It sets up the basic fundamentals of an operating system and gets it ready for deploying the application. 

There are also different kinds of file systems that need to be deployed and additional users that need to be added. Those are all manual processes.

We have one admin who manages all the images. That is the return on investment. The company hasn't had to hire a second admin (FTE) to keep things running.

We have moved to the Simple Content Access (SCA) model. It is much easier to do renewals and see how I am using my licenses. I used to have to do it all by hand. It would take me a good couple of hours every few months to make sure that we were up to snuff on everything. However, with the new model that they have, this is very easy. I just go to cloud.redhat.com to look and see how I am utilizing my licenses. If I am running out of bounds, I can find out why. If it is simply that we have images that need to be removed, we remove those images. If we need to buy more licenses, then we can start the process of purchasing more licenses.

I think it is worth the price. I wish the pricing was a little bit more friendly, so when I go to my boss, he tells me, "That's too much money." I can say, "It's not too much money."

Especially if you are a newbie, buy the support and use the support. Get a couple of images going and really play around with them: crash them, burn them, and figure out how support functions when you have a really gnarly situation. Otherwise, it is just inserting the CD and booting the machine. It is very easy to set up and run.

I have looked at SUSE or Ubuntu. They are so radically different in their total management, e.g., everything from getting packages to configuration and in how that is all done. Therefore, it would be a learning curve to go to another solution. So, there is benefit in staying with RHEL. 

I do not have a lot of experience with Ubuntu or SUSE. Those would be the bigger contenders. The thing that I keep coming back to though as I'm talking to vendors and VARs is that though SUSE is a contender out there in the SAP landscape, RHEL has the stability. SUSE appears to function more like a desktop operating system ported to a server environment, whereas RHEL is built from the server hub. The management tools show that. It is a mature management infrastructure.

There are some things that are nice about SUSE. People talk about their app configuration wizards, but if you're coming from a Unix background overall, RHEL feels like a real operating system.

My interaction with Ubuntu has been as a desktop. It is very GUI-oriented. In my estimation, it is more like a toy. It is deployed in server environments, but it is more because admins are familiar with the desktop version of it. They just port that over as opposed to having grown up on Unix and moved into Ubuntu.

A Unix admin will prefer to go into something like Red Hat, Rocky Linux, AlmaLinux, or even Oracle Enterprise Linux because they will simply feel much more like a data center operating system than some of these other solutions.

RHEL provides features that help speed deployment. I am currently learning how to take advantage of those features.

As far as deployment goes, I build a golden image VM and just deploy the images themselves. I don't really use any RHEL tools specifically for the deployment portion.

The solution is constantly expanding and moving into new areas, like jumping into the cloud.

I need more experience with their self-monitoring tools. That is the one area where I feel like I am lacking. I am still using a lot of the stuff that I learned in the Unix realm. I haven't really matured into using the specifics that are being supplied. I am a member of the accelerators team and have been exposed to some of these tools through their lectures. I am starting to play with them a little bit, but I have not fully gone into that arena. So, there is improvement needed on my access to RHEL.

I would rate the solution as 10 out of 10.

We use it for core infrastructure services, like package mirrors, configuration management hosts, and proxy requests going to the Internet or as reverse proxies in front of our applications. Our campus management software is delivered via RHEL and applications like Wikis learning platforms.

Almost all machines are running on virtualization. Only a few bare-metal systems exist today. Currently, we are not engaged in any kind of public or hybrid cloud environment.

One of the most important features is the package manager. It provides the ability to very easily roll back transactions when something has gone wrong. It is an easy-to-use tool that helps me in situations where something unexpected has happened. I found that this was one of the solution's major advantages over other distributions.

Another point that I really like is the ecosystem around RHEL. Red Hat provides security and bug-fix Erratas for every single update out there. Thus, I have a lot of pretty sophisticated information so I can inform myself about what an update is for, what could happen when I install it, or what would happen if I don't install it. The value added by the information Red Hat provides for its distribution is pretty good.

RHEL provides features that help speed deployment. We use Ansible in our environment, which is the free version that is usable with a RHEL subscription. It is pretty easy to set up a baseline configuration for each system as well as deploying our applications and configuring them.

Ansible and RHEL integrate pretty well. You see pretty quickly that Red Hat has a huge engagement in RHEL as well as in Ansible. They work very well together. This integrated approach decreases the time that we need to set up configuration jobs. It helps us to have faster deployments as well as make configuration changes faster and more secure. It is a tool for everyday use.

We use the solutions AppStream repository at some points. Compared to earlier versions of RHEL, we like that it is now easier to use the newer versions of run times, e.g., Python. 

We use RHEL to run multiple versions of the same application or database on a specific operating system. For example, we run several versions of the MediaWiki platform on the same system. We usually have one version of a database management system per host. If we need another version, we deploy it on another host.

RHEL's feature for managing multiple versions of packages is getting better. In earlier versions, when I think about the Red Hat software collections, it was sometimes pretty hard to set them up and use them on a daily basis. With AppStreams, it got easier. What could still be improved is the lifecycle information about AppStream versions. Usually, when doing a major release, I have 10 years of support divided in different support phases, but a lot of applications from the AppStream repository have a completely different lifecycle so you need to check it separately. For example, a certain node.js version will be at the end of support in 10 months. I must make a note to update to a new version before it reaches the end of support. It would be awesome if the end of support date of the application streams would follow a stricter lifecycle with aligning end dates.

The Authselect tool needs improvement. This tool is used to connect your system to an identity provider or directory service, e.g., openLDAP. There is documentation and descriptions. While there are a few use cases and examples described, it is sometimes hard to use these tools to set up the configuration that we need for our specific environment. I would like it if there was more general information about the tool, not just describing a use case. For example, here is how to do it and how to connect to some kind of openLDAP service as well as more information about when you need to configure certificate services and mutual authentication. There is room for improvement, but it is more room for improvement in the documentation area than the RHEL system itself.

We have been using RHEL since 2016. 

The stability is awesome because we have had only a few issues in operations. Once it is set up, tested, and ready for production, it just runs. For the usual maintenance tasks, like updating the system and making configuration changes, there are almost no disruptions or issues in our environment.

The availability is great. We usually don't have big issues in our day-to-day operations.

When it comes to increasing memory, CPU count, or deploying more RHEL instances, the scalability is good. We don't have any issues. However, I would guess it would be the same with another distribution.

I would rate Red Hat's technical support for RHEL very differently. It depends on the area that you are looking for support. For example, when I have an issue with a RHEL core platform, there are a lot of good support engineers available to help with my issue. There have been phases where one could get the idea that they are short on staff with Ansible experience, but it is now getting better again. However, the average experience and response times are good. Their responses are also good. When you have a difficult case, they are able to escalate it quickly. Therefore, you get an engineer with the appropriate background to help solve your issue. I would rate the technical support as a solid eight out of 10.

Positive

I was part of a working group who decided which major enterprise distributions we would introduce into our organization. Before 2016, we only used a very small number of Linux installations and different distributions. As an outcome of this working group, we decided to use RHEL and have used it since as the only distribution in our data center. We migrated from other distributions, such as SUSE Linux Enterprise or openSUSE, to RHEL.

While all distributions share a Linux kernel, there are differences in how to manage the distribution itself. A very important part is the package management. When you have to deal with tasks like updating packages, downgrading packages, and repairing damaged package databases, you want to have one package management tool that you know very well, not three different package managers where you only know the basics. To ease the management of multiple hosts, we decided to migrate to only one distribution. We hoped that we would have an advantage in consolidation. 

The complexity of the initial setup will depend on the requirements of your organization. Generally, I find it pretty straightforward. There is good documentation for it. The installer works great. I haven't had any issues.

There are special academic offerings for academic institutes, which is pretty good. We need these offerings. In my personal opinion, the prices are okay. However, for educational purposes, they could be lower. For example, in Germany, the budget in the education sector for IT is lower compared to the huge universities in the US.

When you are only using the RHEL subscription system, it is okay. It can get complicated very quickly when you need multiple different subscriptions with a lot of SKUs. 

When someone is going to look into RHEL, I suggest starting with an individual developer subscription, which everyone can get for free. With developer subscriptions, you won't be able to contact support, but you have almost all of the important applications and features of RHEL for free. You are not allowed to build your whole production on it, but you are able to develop applications, test configurations, test the platform, and try out almost everything.

In our IT environment, we were running Solaris and Microsoft Windows. It was decided that we wanted to move away from Solaris to some Linux distributions. In the process, we looked at distributions, like RHEL, Oracle Linux, Debian, SLES, and Ubuntu. We looked at all of these points: 

• What are the management tools? 
• How does it look in the ecosystem? 
• How many packages are available and the distribution repositories? 

We created huge metrics to score all these different points. There were over 200 points to score for the different distributions. In the end, RHEL was our winner.

Red Hat’s open-source approach was an important factor when choosing this solution. For example, let's say I won't use OpenStack from Red Hat anymore. There are other OpenStack distributors out there who know the application and can help us in the migration process. It is the same with the platform. At the core, the Linux distributions are pretty similar. We believe it would be easier to move to other solutions from other vendors compared to operating systems or software from proprietary vendors.

We have plans to increase usage. Every new application that supports running on Solaris or Linux is going to be deployed on RHEL these days. I hope it will be our major operating system in the data center. So, in the foreseeable future, there would only be two operating systems: RHEL and Microsoft Windows.

I would rate this solution as nine out of 10.

Our use case is mostly for application servers. We are not really using it for any of our file servers. We have a storage department who usually just deals with NAS and things like that. However, this solution is primarily for application servers.

The biggest benefit is from a security standpoint. As the product progresses and they come up with new versions, the new security features are addressing vulnerabilities. From that perspective, it has worked well.

We use Red Hat Satellite. The integration between Satellite and RHEL works well. Satellite is mostly used to manage the repositories from a secure standpoint. We also use IBM, which is for identity management and user access, and that also works well. From an operational standpoint, it works great. We are able to manage user access with IBM, and there has not been an issue. We make role and user groups as well as host groups so different groups have access to different servers, for whichever servers are in different host groups. For example, the database team may have a user group who has access to all the database servers listed in a host group. So, the access works well.

The best feature is its dependability. We have had some situations where some RHEL servers have been up and running for five years. So, it provides reliability and dependability. It stays up.

It provides flexibility for us to come up with solutions to speed up deployment, which is great. It allows us to use it in different environments and works well with different applications. For our virtualization platform, we will just probably deploy through VMware. We are able to script and code all of the hardening procedures. If we wanted certain applications installed for deploying images, it just gives us the flexibility.

The deployment and management interfaces for non-Linux users and Linux beginners are pretty robust. It works pretty well. I know the servers themselves have a UI that is a management front-end, where you can basically do everything using the UI rather than doing anything with the command line. That is definitely good for non-Linux users and Linux beginners.

The consistency of application and user experience, regardless of the underlying infrastructure, is great. It works well. The more that they add to make it a little simpler to work with the tools and applications that they provide, the better.

The solution enables me to deploy current applications and emerging workloads across bare-metal, virtualized, hybrid cloud, and multi-cloud environments. If it was a scale of one to 10, 10 being the best, I would say nine because there is always room for improvement. It is definitely up there as far as its reliability.

In the past and with older versions, you couldn't expand the root file system without rebooting the server or restarting the operating system. That is something that they have actually corrected now, which is great. They corrected that issue somewhere around RHEL 7. 

Since 2005, I have worked at various companies who have used this solution.

My current company was using it even before I came.

Once it is up and running, it is solid and stable. It has a stable OS. I haven't had any issues with it.

Usually, if there is any particular issue and it gets to a point where we need to open a ticket, then we will open a ticket and just generate a dump file. We then upload it and wait for them to respond.

The technical support has been great and awesome. They have been able to assist, provide solutions, and root cause analysis for different issues. I would rate the technical support as nine out of 10. There is always room for improvement.

Positive

Before 2005, I worked as a Unix engineer for Solaris and Sun Microsystems. Once I left that company who was working with Solaris, that is when I started being more like an administrator for Red Hat Linux for different companies.

Most companies go with some sort of way to deploy an image. I have done standard, straight installs, installing the solution to laptops. That would be the equivalent of installing it to bare-metal.

It takes maybe 15 to 20 minutes to deploy a server. That is just with all the automation that we have added as well as having to deploy a base OS image, hardening, and adding all the software that we want. For a company-base installation, it takes about 20 minutes.

This solution is definitely one of the best versions of Linux out there to use, especially if you are looking to use Linux in an Enterprise fashion. This is mainly because it has the best support out there. It is also stable and dependable.

We use outside monitoring tools, not the ones that come with RHEL.

We are using other tools to deploy base images to our private cloud. So, we're not exactly using Red Hat tools for this use case.

They are a great company overall. It is hard to say where they could improve. They have user groups. They put out a lot of messaging and information. The solution is easy to learn and get to know their products and what they do. From a personal standpoint, I have everything that I need.

If I wanted to run multiple versions of Node.js, there are ways to do that without using AppStream. More recently, I have been working with different versions of Node.js, having it in different versions on one machine. It works well. Just the fact that I have the capability is great.

Among the other distributions of Linux out there, I would rate it as 10 out of 10. If I have to compare this solution against everything else out there, this solution is at the top of the list.

It is used for our production system. We are running multiple web servers and multiple databases on RHEL operating system platform. We are also running some of our OpenShift containers on it. We have a lot of applications that are running on RHEL versions 5, 6, 7, and 8 in our environment, but the maximum number of applications are running on RHEL 7 and 8. 

RHEL provides features that help speed up our deployment. We are using OpenShift to speed up our container implementation and container orchestration.

It is good in terms of consistency of application and user experience. It works consistently regardless of the underlying infrastructure. For the features we are using, we are getting the output according to what they have mentioned in the portfolio. We are not facing any unpredictable issues. It has a predictive analysis feature for troubleshooting. It uses AI and ML algorithms to give us the issues that will eventually come if something prolongs. If we are managing our environment very well and are following the best practices, our end-users also don't face any issues, which improves their user experience.

We use RHEL's tracing and monitoring tools. They have given a lot of metrics, and we do use these tools to trace our application. They provide a lot of benchmarks and metrics if we are planning to do a tech refresh or if we are planning to migrate any solution. So, we use them to calculate, and then we do the documentation.

Its integrations are very reliable. We have a Satellite Server for patching, and we are using Ansible for configuration management. We have a lot of API integrations with the RHEL for third-party integrations. We do a lot of testing before integrating the third-party services into RHEL. We first try them out in the test environment, and then we deploy them on the dev environment, and after that, we move them to the production environment.

It is easy to manage. It is also easy to troubleshoot. The subscription and the support from the RHEL are also good.

It is a well-established operating system. We have tried to implement almost every feature of a version in our environment, and it has been very reliable. We are not facing many production issues on a day-to-day basis. They have well-documented articles on their documentation site and a knowledge base on their website. When we need to implement anything, we are able to find information about the best practices and the solution.

Their support service can be improved. They are able to help us, but in some cases, there is a delay in getting a root cause analysis from their side for Severity One cases.

The vulnerability assessment part should also be improved. We do a lot of patching regularly. They try to fix an issue very quickly, and we also end up facing bugs that are not properly documented. When releasing the general availability for a particular solution, they need to do a lot more work on their side.

We have been using this solution for more than eight years.

Its stability is awesome when compared to other products. We have multiple Unix flavors running in the environment, but we are running production workloads only on RHEL. Previously, we were running the production load on other Unix flavors, but we had a lot of production issues. That's why we migrated the whole production workload to RHEL.

Scalability is according to each product. They have predefined scalability ratios. It works fine according to that ratio. We are able to scale applications and databases. It is easy. Before deploying an application, we check the scalability of each product, and we plan accordingly. So, there are no issues. It is easy.

We have Oracle Databases with 30 to 40 terabytes database size running on RHEL. We also have some HPC systems running on RHEL. We are running a workload of around 250 terabytes on RHEL, and we are planning to extend our environment and increase its usage.

Their support is good, but there are some delays in giving a root cause analysis for critical Severity One or S1 cases. I would rate them an eight out of 10.

It is straightforward. It is not much complex. Previously, we used to do everything manually. Now, we have multiple scripts and multiple tools that make it easy to deploy.

The first deployment took a few months because we were new to RHEL. We had to do a lot of homework from our side as well as on the product side, so it took us a few months to implement it. Now, we are well-familiar with the product. We know how the product works, so we plan accordingly, and we are able to finish according to a deadline.

RHEL has accelerated the deployment of cloud-based workloads. We also work with a local partner of RHEL, and they give us professional services. They do have some customized tools for partner deployment, and their professional services team is able to help us to accelerate all the workloads to the public cloud by using those tools. This acceleration time depends upon the workload size and whether we are going for a normal Infrastructure-as-a-Service or Platform-as-a-Service. It also depends on how we are migrating our monolithic application to the microservices application.

We are a local government organization. We have an account manager from RHEL, and we also have a local system integrator and a local partner. They are providing us local help for our requirements.

For purchases or subscriptions, we don't have any issues. We have multiple subscriptions for multiple products. Our local Red Hat partner takes care of all requirements. We just send the requests to them, and they take care of all subscription-related things for us. The whole process is streamlined.

We have been using it for a lot of years. Our business is happy with its total cost of ownership and its return on investment.

It is more expensive than other vendors in terms of pricing and licensing, but because of its stability, I have to go with it.

In terms of the operating system features, scalability, and stability, RHEL is better than other Unix flavors.

We do a lot of technical evaluation before migrating or implementing a new application or solution. For example, we evaluated Docker, Kubernetes, and OpenShift. We went for OpenShift because RHEL had the support for it. For patch management, we are using Red Hat Satellite Server. We used some other third-party tools such as ManageEngine, and we also did manual patching. As compared to others, Red Hat Satellite Server is much better.

It is very stable, and you can easily run a lot of production workload on RHEL. Red Hat products are well established. They have been around for many years. Red Hat is dealing with multiple products and applications and is constantly doing research to develop new products according to industry trends. With RHEL, you can get an end-to-end solution with their multiple products, which is something not available through other vendors. 

Red Hat's open-source approach was a factor when choosing RHEL. We are utilizing a lot of open-source solutions in our Test and Dev environment before going into production. We are able to get a lot of information in the open-source community, and we also have local community support in our region.

Its newer versions enable us to deploy current applications and emerging workloads across bare-metal, virtualized, hybrid cloud, and multi-cloud environments, but the older versions are not supporting these features. They have included more features in the newer versions to integrate and merge with other applications that are on-premises, in the cloud, or in a hybrid cloud setup. In the older versions, we faced some issues in moving some of the applications from on-premises to the cloud, but in the newer versions, it is very easy to move or merge to the cloud. The applications that we have deployed across these environments are very reliable, except for the bare-metal. They are not much reliable if we are using a bare-metal solution on-prem. For virtualization, we are not using the native RHEL virtualization. We have VMware for virtualization, and it is okay in terms of directly deploying some of the applications to the public cloud. It is quite reliable.

It doesn't simplify adoption for non-Linux users. For non-Linux users, it is somewhat difficult to manage this solution or have this solution. However, as compared to other Unix platforms, RHEL is okay.

We are not using RHEL to run multiple versions of the same application or database on a specific operating system. In a specific operating system, we are running an application according to our end-user features requirements. We go through a lot of documentation and do multiple PoCs for deploying an application on the RHEL platform. We have a lot of user acceptance test procedures for each application in terms of how we have to do benchmarking and what are our requirements. So, we are managing with an individual operating system and not using the whole centralized solution.

We use automation tools to move to the cloud. When we are planning to move to the cloud, we do multiple cloud assessments for which we have third-party tools as well as in-built RHEL tools. Each vendor has a different way of migration and automation for moving the on-prem workload to the cloud workload. Each vendor gives you different tools, and we follow the best practices given by them while moving the on-premises workload to the cloud.

I would rate RHEL an eight 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.