Red Hat Enterprise Linux (RHEL) Reviews

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.

We use a combination of Red Hat and Oracle Linux in different parts of the organization. We have a cluster, where RHEL is running. The instances are both virtualized and real, depending on which part of the cluster you're utilizing. They are set up as either RAC or single instance, depending on what we are trying to achieve in terms of performance.

We have PeopleSoft systems that are all deployed on Red Hat. We also use it for deploying simple websites. PostgreSQL is running on the systems, along with a frontend that was created by the developers. We also use it for DNS fallback authentication.

We have quite a few Windows systems, as well, and some of the applications that we used to run on Linux have now been migrated to Windows.

We have a mixed environment, although, in the cluster, our deployment is primarily on-premises. There are some deployments into different cloud providers, depending on the service that we're looking for. However, when we head into the cloud, we tend to go to Product as a Service rather than Infrastructure as a Service or the like. This means that we're less concerned about the underlying operating system and we try to avoid interacting with it as much as possible. So, it is just virtualization in this case.

We rely on RHEL for stability, control, and reliable updates. There may be other Linux variants that work as well or better but we're quite happy with this solution.

We try very hard to ensure that everything is working irrespective of what it's running on, in terms of the operating system and middleware, including what database is running. RHEL helps maintain consistency of application and user experience, regardless of the underlying infrastructure, simply by not being part of the problem.

RHEL enables us to deploy applications across bare metal servers and virtualized environments, and it's an area where everything seems to be working okay. It is reliable and there is nothing that is causing us grief at the moment. The only ones causing us trouble are the applications that we're customizing, although that is nothing at the operating system level.

You can set up the security services quite quickly, which we found very useful in our context because we're a highly public organization and we need to ensure that we've got things patched as quickly as possible.

This is a very robust product that doesn't require a lot of handling. It just works. It doesn't really matter whether we've got Apache components on it or anything else. It'll run.

We have used RHEL's monitoring tools, albeit very rarely. The last time we used this feature, we were trying to track down a problem with one of our LDAP services and we were not getting any useful response back from support for that service. Ultimately, we were able to track the issue to a particular character in a user's surname.

There is nothing to work on in terms of speed and performance.

We started using Red Hat Linux approximately 15 years ago.

Overall, the stability is very good.

The most recent stuff that's been a little bit kinky was in the release of version 8. They were looking to change things around with how the product is built, so it just took us a while before we started using it.

I think we waited until version 8.1 was out and then we were fine. It was a case of us letting that version settle a little bit, as opposed to version 6 and version 7, which we went straight to once released.

Scalability-wise, it suits the needs of our organization and we haven't tried to do anything more than that. When we had multinode, Oracle RAC systems, we had a four-node RAC, each of them had four CPUs and 64 gigs of RAM, and they were all running one database. Performance was not an issue with the database.

This is one of those systems that people can use without knowing it, in a web context. Pretty much all of our research staff and students are using it, at least to a degree, even if it's just for storage management. From their perspective, if you ask them what they're using then it's just a Windows share, but in reality, it's RHEL. There are between 30,000 and 50,000 users in this category, and the majority of them wouldn't even know it was Red Hat.

We've got a fairly straightforward Red Hat implementation but the users do a variety of jobs. Some of the work that we do is implementation integration, so there are no specific users per see. It's just about migrating data and files, depending on what we need. The people that use it in this capacity are academic staff, finance staff, libraries, IT staff, students, and researchers. It is also used by systems engineers, senior systems engineers, the senior security person, my manager, and his boss. There is also a deputy director and the director.

We're probably not going to increase our usage by any level of significance. At the same time, we're probably not going to decrease in any great rush either. We're in a phase where we're looking at what can be put into cloud systems, and we are targeting Product as a Service in that space rather than infrastructure.

Essentially, we're looking to move away from managing operating systems when we put stuff in the cloud, but we still have hundreds of servers, just in one of our locations. The majority of them have no plans to move at this stage, so our installed base is fairly stable.

Primarily, we haven't had to use technical support and I can't recall the last time we actually had to log a call with them. It's a really good situation to be in.

It's an interesting situation because we use Oracle Enterprise Linux primarily. It is really not very different from RHEL because it's just recompiled and they resend it. We use RHEL on one of our clusters, which has about 300 nodes in it and is used in research. In short, we use both Oracle Linux and Red Hat Linux, but the reality is that nothing much is different between the two of them.

We initially implemented Red Hat and we consolidated everything to Oracle Linux because it was cheaper from a support standpoint. That was when Red Hat Enterprise Linux version 4 was out. I think that version 5 had only just been released and we switched to Oracle, which is the same thing anyway.

The last time the research cluster was updated, it switched from the IRIX operating system to Red Hat on HP. They weren't necessarily going to implement Red Hat but we had to make sure that everything was licensed correctly, and that's how it came into play. Since it is not using our Oracle license, but it's already bought and paid for, we have not consolidated it. We could consolidate again but it doesn't make a lot of difference in terms of what we do on a day-to-day basis. It runs the same and it operates the same.

We were running version 7 of Red Hat on the cluster and we have versions 4, 5, 6, 7, and 8 running in the Oracle Linux space. The applications running on version 4 will only run on that version, and there are only two of those left. We have three instances of version 5, about 30 running on version 6. We are trying to reduce this number and we had more than 60 running on version 6 a few months ago. The fact that this is going down is nice.

Versions 7 and 8 are still supported, so the specific version is not a concern.

Prior to using Linux, we used Digital's TruCluster. However, after Digital was bought by HP, they discontinued the product.

The initial setup was fairly straightforward. We put in the satellite server and then ran the config on each of the nodes to tell them where it was. After that, the updates were happening and there wasn't anything else to be done.

We did not use a formal approach for our implementation and deployment. It was probably more haphazard than structured.

We implemented it in-house.

We have four people that support it, although they do not work on it full-time. For example, the person who works on it most consistently also does work in the networking and firewall space, as well as identity management. We have more support staff for Windows within our environment.

The most recent change we made is a flag that had to be set on the kernel for some of the machines. Setting the flag means that you can patch it without having to reboot. This wasn't particularly problematic, although we had to make sure that it was in place because we now have patching occurring on a monthly basis.

In general, there is not much to do in terms of maintenance. The biggest drama has come from organizing upgrades to the application side that sits on top, rather than the operating system itself.

We've had some done ROI analysis over the years and it's always interesting when you read them. When you consider the initial implementation and you couple that with what we did with Oracle, we saved about $500,000 USD on purchasing all of the different parts by going with Red Hat.

This is significant as well because we still had the same capability with the hardware.

We've had similar kinds of examples thrown at us over the years, but primarily that's when comparing HP-UX and other vendor-closed products.

The price is something that can be improved, as they are still being undercut.

We are an educational institution and as such, what we pay is less than the average company. There are no costs in addition to the standard licensing fees.

Red Hat's single subscription and install repository for all types of systems is something that we're quite interested in because it's simpler and easy to manage hundreds of virtual machines. However, from a pricing standpoint, it's part of the problem because it's what Red Hat utilizes to explain why they cost more.

The Oracle licensing of support for the same Red Hat product is cheaper, and it's cheaper to the level of significance that it makes it worthwhile. We have spoken with the salespeople at Red Hat about it, and they have said that there was nothing they could do.

It's starting to become a question mark over the patching with version eight. We might be changing, but we're unlikely to be changing from Red Hat. It's more a case of who's running our support, be it Oracle or Red Hat. However, we would need to look at the numbers next time we renew, which is not until next year.

Prior to choosing RHEL, we looked at a number of different things. We conducted a fairly large scan of product offerings and our analysis included cost, availability, and support. It took us about three months to go through the process and Red Hat was successful.

The fact that Red Hat is open-source was a consideration, but it wasn't necessarily a winning ticket at the time. We came from a closed source product that we were very happy with but when we were looking at the alternative closed source options, none of them were even close in terms of product offering. Also, they were actually more expensive. So, when looking at the open-source with support opportunity that we were presented with from Red Hat, it was very much a cheaper option that also brought with it a lot of reliability. That is why we chose it.

RHEL provides features that help to speed deployment, although we don't use their tools. We use tools from a third party.

My advice for anybody who is looking into implementing RHEL is to make sure that it is going to work for you. Ensure that it supports all of the products that you need it to support once you've actually assessed all of those things. It is a quality product, there's no doubt about that. Once you have made that assessment, I would say, "Great, go for it."

In summary, this is one of the products that works well and does what we need.

I would rate this solution a nine out of ten.

Currently, we're running our web servers on Red Hat Enterprise Linux. 

It improves our security posture, especially around patching. It has built-in security features for risk reduction and maintaining compliance. SELinux, which is basically the default firewall provided by Red Hat, allows me to secure myself in terms of the network ports that are exposed or enabled, which reduces the risk. When you have a web server, you have a public IP, and for the public, it's easy to do a port scan on that particular public IP, but when you do implement proper security controls in terms of firewalls, you're able to enable only those ports that you need for communication. For example, for a web server, you'll enable port 443 for HTTPS and one or two extras for a particular requirement for Tomcat or something else. The setup and configuration are quite easy. OS-level patching is a big deal for us for maintaining compliance. With the enterprise subscription, you do get patches as soon as they're released by Red Hat.

It helps with portability. I can take a snapshot of my Red Hat virtual machine and restore it anywhere regardless of the virtualization platform, as long as the processor architecture stays the same. For example, if you're doing a backup and restore from a RISC-based processor, you can always restore it to any other RISC-based processor. Similarly, if you're taking a backup or a snapshot on any X86-based processor, you can restore it on the same processor architecture, regardless of the platform you're running. It could be Dell, IBM, or something else. Portability is a huge but often understated feature. It means that if a server has gone down, regardless of the issue, when I have the backup, I can get my services back online in a matter of minutes by just doing a snapshot restore from one server to another, or from one container platform to another. It enables me to have the highest levels of uptime for my applications. Of course, it's also impacted by the hardware I'm running. I'd rate it a nine out of ten in that aspect.

Standardizing our web applications with Red Hat Enterprise Linux has enabled us to take advantage of automating some of the workflows. For example, previously when I had a mixture of different distributions, if I wanted to deploy a particular setting across all of them, I had to do configurations on each distribution separately, whereas now, all my web servers are running on Red Hat, so I can create a simple YAML script and apply the same configuration across all of them. 

In terms of development also, configurations have been evened, and when you're taking advantage of open-source tools, it even becomes easier. We've integrated some of the native tools, such as YAML, into our CI/CD pipelines, and it's easy for our developers to deploy the same source code across different servers. For example, if you have Application A that is clustered across three or four servers, you can easily use that one single pipeline and do the same configuration across all three clustered servers. It saves us time. We are also getting a bit of quality control because we are sure that the same configuration has been applied to all three clustered servers. It has enabled us to centralize the process of DevOps in our organization.

The first one is security. Initially, the reason for going for Red Hat was mostly around security because our web servers are normally public-facing, but now, all the other distributions have probably also caught up in terms of security settings. 

Aside from security, the advantage of Red Hat as compared to the other distributions is the availability of support and patching. When you have an enterprise subscription with Red Hat, you get support and patching. If you're deploying a new product in the market and you're not sure of its compatibility with Red Hat, you can easily reach out to their support team, and they'll be able to guide you about whether they support that particular product and how far have they gone in terms of testing how Red Hat works with that particular product. For example, we were deploying a new Nginx server a few months ago, and we were not sure whether the latest version was supported by Red Hat. We had a support call and got one of the engineers into a session, who was able to take us through the level of support provided by the Red Hat operating system for the latest Nginx application. Support is very crucial in such cases. Patching is also crucial. In the case of any common vulnerability exposure that has been or can be exploited, you can rely on Red Hat to quickly patch that vulnerability.

One of the reasons for preferring Red Hat is that you can run it on X86-based hardware from Intel or AMD, or you can run it on RISC processors, such as IBM or Sun Microsystems. In terms of portability, it's supported by all the virtualization platforms out there, such as Hyper-V, VMware, and OpenShift for containers. For portability, I'd rate it a nine out of ten.

Deploying clusters on Red Hat, as well as on Oracle Linux, is a bit involving. I'd like them to simplify the setup or at least give meaningful log files to be able to see what's happening at the cluster level. 

It has been close to 10 years since we have been using it in our organization, but personally, I've dealt with Red Hat in production for two years.

It's quite stable. I haven't had any issues in terms of performance and stability with my Red Hat servers. If I have an issue, it's normally a hardware-related issue or a storage-related issue. It's rarely at the OS level.

It's quite scalable. I personally haven't had any issues in terms of scaling Red Hat, be it in a virtual machine or be it through a container. I haven't had any issues in terms of scaling. I do know one limitation they have, but it applies to very few people. For example, the amount of RAM they support does not reach one terabyte. However, I've not had a use case where I needed to have one terabyte of RAM on one particular server.

We have around 20 Red Hat servers. They're distributed across Azure and on-premise. They're normally running web services. Most of the applications they run are accessed by everyone in the organization, and there are 3,000 to 5,000 users.

So far, I've not had an incident for which I needed to take their support. I have not yet contacted Red Hat support.

We were mainly running CentOS, but then Red Hat dropped their support for CentOS. For us, our security posture is highly important. Our major pain point was around patching. Whenever we had any vulnerable web servers exposed to the public internet, we were not able to get patching for any CVEs that were found. That's why we switched our web servers to Red Hat. Patching was Red Hat's main advantage. In terms of security features and control, such as user management and permissions, Red Hat is quite similar to other distributions. I don't see any difference in terms of other aspects. The switch wasn't because of a lack of features, but after switching to Red Hat, we are now exposed to their enterprise features or tools, such as OpenShift. So, our investment in Red Hat was because of their support and patching.

We have deployed Red Hat on-prem on Hyper-V. We've also deployed Red Hat on-prem on VMware, and we also have Red Hat on Azure Cloud. In terms of version, we have everything from 7.2 and all the way to 7.6. We currently don't have any real deployment of version 8 or version 9.

I'm the person who does most of the deployments. The deployment is quite easy. I'd rate it an eight out of ten in terms of the ease of deployment. Deploying Red Hat would be quite easy even for a beginner system administrator because it guides you during the deployment. It asks you whether you want to use a feature or what features you want to install alongside the operating system. Do you want a file server, or do you want a web server? The installation is quite straightforward and simple.

For me, normally the complete configuration from deploying the OS and managing storage, users, and security takes less than 30 minutes. In less than 30 minutes, I'm usually up and running.

We do everything in-house. We don't use any third-party help. Usually, I do all the deployments myself, but I also have an assistant. So, we currently have two people: me and my assistant.

It doesn't really require any maintenance. It just requires occasional patches. That's also handled by me and my assistant.

There is definitely an ROI. Automation definitely reduces the time taken to implement a particular task and the number of employees needed to do the same task. For me, it's majorly in terms of automation, uptime, and availability. The fact that Red Hat is quite portable means that whenever one of my systems goes down, I can easily just take a snapshot and get my services back online. 

Their licensing is quite okay. It isn't expensive, and it's slightly cheaper than Microsoft. Taking into account its features, its price is okay.

Support is something that serious enterprises would want to have. The advantage of running an open-source tool is that you do not have to pay for the tool in terms of licensing, but you don't have support. In certain situations, you might need support. For example, when one of your systems goes down, but you do not have the expertise internally to recover it. Depending on the industry you're working with, having downtime might not be optimal or might be costly. It might even be costlier than paying for the support or licensing of Red Hat.

Apart from support, for organizations that have some of their services exposed to the public internet, security is very important. They would want the patches for the latest common vulnerability exposures found to be affecting the particular systems they are running. So, support and security are the key features why any serious organization should choose Red Hat as opposed to an open-source tool.

We evaluated other options, but they were probably inadequate. We had the option of using AIX, but it wasn't portable for our use case. 

It's normally an issue of balancing the cost of support and the features that you are looking to achieve. If security is number one to any organization, Red Hat is a no-brainer. If support is a key issue, Red Hat again is a no-brainer. If you're facing any security or support issues, I'd recommend going with a distribution that has some sort of licensing tied to it.

I'd rate Red Hat Enterprise Linux an eight out of ten.

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're the largest financial institution in Africa, and we use various operating systems and technologies to achieve typical financial service goals. In the past, we were an ION-centric shop. However, in the past decade, we've been increasingly leveraging Linux's agility compared to traditional Unix operating systems. 

Generally, we deploy by cloud, but we use RHEL on-premise in our data centers and prefer SaaS for infrastructure as a service. Our primary cloud providers are AWS and Azure, and we also use smaller third parties for niche environments.

RHEL is spread across virtually all elements of the institution, including headquarters and various locations on multiple continents. In my environment, it is part of a global trading settlement system. 

The rollout for this particular solution was probably about 250 users of the application running on the initial RHEL. We're a global bank, so the user base is much larger worldwide. Users include business and feature analysts, engineers, and project managers. Our infrastructure engineers were the ones pushing for a switch to RHEL, followed immediately by application engineers.

RHEL enabled us to move away from reliance on ION. We're free to choose the best-of-breed solution at any given time while keeping the cloud-agnostic infrastructure at the center of our deployments.

Our operational expenditures decreased, and RHEL made our teams much more flexible. With RHEL, we can have multiple copies of an OS without making annual plans to license and acquire.

The benefits were instant from my team's perspective. For example, we were immediately more flexible and able to scale rapidly. However, if you're looking at it from an executive point of view, the time to value depends mainly on the product and the scale of the endeavor. It might take a few years to reap a return. Ultimately, you will see the financial benefit, but that's somewhat difficult to quantify in the short term. 

I don't think that it's enabled us to centralize development, but it has perhaps increased the breadth of development possible on our applications. In that sense, more development can be centralized on the operating system, but that's more of a byproduct.

We outsource cyber security to other teams, so I can't comment in-depth on RHEL's security features, but I can say it enabled us to understand our security posture more efficiently. This wasn't always possible using an AIX or Solaris in a more centralized fashion. The feature set is maybe not as important as having a single pane of glass and a single configuration to apply across our systems and infrastructure.

RHEL made life a lot easier in terms of compliance because you can more accurately gauge yourself against industry benchmarks with the tools provided and identify your shortcomings. You can interrogate what you've done through research from multiple parties rather than just a single source of truth, which may not be true.

You can compile and run applications on any operating system, but RHEL's advantage is flexibility. It is more supported and supportable in the enterprise sense than Ubuntu or perhaps a smaller distro, but it's also flexible enough to easily transport from platform to platform: ISA to ISA,  production to development, and vice versa. That led me to embrace the switch to RHEL from other operating system variants.

RHEL offers more portability than any other OS flavor apart from perhaps Ubuntu Linux. As a large bank, we run on IBM's architecture. We run Power, Spark, and Oracle x86 across multiple environments. It lets us choose the right environment for the application, which is essential from an operational efficiency perspective. These days, we're all trying to cut heavy infrastructure and move to lightweight agile infrastructure. There isn't a better option in the production world than Red Hat.

There needs to be a broader understanding of the RHEL suite's nuances like how the versioning works and implementing it on various kinds of infrastructure in use across the development landscape. There needs to be more training and education. It's difficult when you have a roadmap to deal with, but it is possible. 

Large application vendors may not have certified RHEL, or they have certified an older version. Most of the large application vendors are unfamiliar with the versioning that RHEL introduced, which I strongly support. They will support a given sub-version up to a point, not realizing that the sub-versions are essentially additive. 

This can be a real frustration when you try to deploy modern infrastructure. It allows tremendous flexibility because we can try things out across the cloud, virtual, and physical, but that's not always where the issue is. It's a matter of educating the engineers and developers on our side or enterprise vendors on the other. 

The licensing could also be simplified. While it makes sense from a theoretical perspective, it's a challenge to explain to the procurement team. Those with some technical expertise can understand how our licensing model works. However, it's still tricky because Red Hat is so different from traditional operating systems. It's another barrier when I'm trying to deploy it in an enterprise environment.

In terms of feature requests, I would point out that our company tends not to operate on the bleeding edge for obvious reasons. We look at what has already been released to define our roadmaps. There's nothing in particular that I would say needs to be included. However, I would like to see Arm playing a more prominent role in the cloud infrastructure and enterprise physical data center spaces. Red Hat supports this, but I haven't seen a clear roadmap for how that support should evolve within the Red Hat operating system environment. 

I have used Red Hat Enterprise Linux for more than 10 years.

RHEL's stability is good. 

RHEL is highly scalable and we plan to increase usage. 

I wouldn't rate Red Hat support as less than eight out of ten because I can't think of anything negative to say. I can't think of a time when I haven't been able to get it. Also, because RHEL is global and Linux is open-source, you can typically get the support that you need through research forums and the knowledge base. It's seldom necessary to involve third-tier support within RHEL.

Positive

We still use other operating systems. We've used just about every solution you could name in conjunction with RHEL. We also deploy Ubuntu. In some cases, our application vendor requires us to stick with a given solution. Sometimes it's AIX or Solaris, but mostly we can override that and move to RHEL. Red Hat is now standard for most future enterprise deployments, and we run RHEL on mainframes too, but in a very limited fashion.

The setup was complicated only because the applications we were trying to run were not certified to run on RHEL. It was version 6.8, so we worked with major global vendors to add the certification for the versions we were trying to run. That was the complexity. The application always worked beautifully, and the performance was excellent. It wasn't a question of getting the development to work; obtaining an issue of getting certification for the platform, which is required for any financial institution.

From a development perspective, we proved the concept and ran a mirror of production and development to demonstrate the improvements in OpEx and performance. Getting it up and running in parallel was the key to getting it all to work correctly, and it was instrumental in convincing any dissenting voices of the value. 

The deployment took less than three months, but the certification took nine.
The team supporting the first application numbered around 50, and the small group involved in the initial switch had about eight people.

The entire application is run exclusively on RHEL, so the whole operation team is probably around 40 or 50 people. It's worth adding that our overall group runs about 20,000 servers, so it's challenging to say overall what the RHEL footprint is.

After deployment, RHEL requires maintenance to keep the solution up to date. Security requirements tend to be more prohibitive or less encouraging of change. It's a question of changing mindsets and explaining that something doesn't have to be legacy-tested to update. The security benefits of updating are more critical than testing to ensure the update hasn't introduced more flaws.

I don't have the data, but we have significantly reduced operational expenditures since switching to RHEL. It was a reduction of more than 10 percent. 

The licensing is tricky to understand. Enterprises want to be beyond reproach when it comes to licensing. We would rather over-license than under-license. However, that can be complicated with a high-performance development team who may need multiple operating system instances or want to experiment with spinning up many machines to see if something works or sticks. 

We don't necessarily need support for those. Our procurement team is confused if we need a license for an instance that was only up for 15 minutes on Thursday. We need to make sure that we always have sufficient licenses. That misunderstanding of how cloud development works can sometimes slow down development. It inhibits the growth and success of Red Hat Enterprise Linux globally. So more education around that would be beneficial or at least will provide more clarity.

RHEL's total cost of ownership is difficult to quantify, but it's almost irrelevant. In cases where you don't care, you can always use an open-source OS. In other cases, you need the support and certification that comes with something like RHEL. I do not believe RHEL has any competitors in our use case.

I rate Red Hat Enterprise Linux nine out of ten. My advice to prospective users is to try RHEL out and see if your application works. In the long run, the benefits will outweigh the time and effort spent migrating. The important thing is to ensure you run programs in parallel so you can accurately evaluate the benefits and make a case for switching.

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.

The main use case is general system administration, which includes configuring networking, configuring storage volumes, managing users, and running backup applications.

Application performance is one of its main benefits. The applications that run on RHEL are very stable. 

I've not done much work with containers, but with general applications, as compared to other solutions that I've used, RHEL has the best portability. I have not had any issues or application failures while migrating. I've moved virtual machines and systems from one platform to another, and I've never been scared of RHEL. I never had to deal with application failures while moving them from one place to there. That's why I'm pretty confident with RHEL when it comes to working with it.

I like its integrations. I would put it higher than any other Linux version when it comes to availability. Its integrations with different applications and solutions are the best. We work with a lot of clients that use RHEL, and we could easily and quickly integrate any cloud solution, virtualization solution, storage solution, or software with the RHEL system. It is better than the other solutions we have worked with.

I like the way the updates are done and the way packages can be installed through the Red Hat Package Manager. I like it because of how fast and straightforward it is.

Its user interface could be better for people who want to use the GUI. They can provide a better user interface with more features. Storage works perfectly fine. Of course, continuous improvements should be made all the time, but it isn't at all lacking when it comes to storage and other features.

I've been using RHEL for four years, but in the last 12 months, I've used it more.

It is the most stable one. It is very stable. 

It has the ability to scale. I know that it can scale, but because of my limited experience with scaling, I don't know how good scaling is. I have only done the basic scaling, but I would assume that it can scale way more than what I have done.

Most of my usage of it is on a private cloud. I've used it in a hybrid cloud environment, but I've not done a lot of work with the hybrid cloud because most of the clients we work with have private clouds. The little bit of experience I have had with the hybrid cloud was related to basic application installation and scaling. For the scaling part, I was able to have the applications first in the private cloud and then migrate or move it to a hybrid cloud. I was able to integrate them, and I was able to change the environment, as well as have them work in a cluster. The scaling part was seamless. It was pretty easy. It was easier than I thought.

The private cloud is deployed at three locations. The public cloud is deployed across two regions. There are a lot of users of this solution. There are different systems for different applications and different services. I can't put a number on the total number of users. Some systems have 50 and some systems have close to 70. There are systems with just 10 or 5 users.

They can be faster. Because I work in support, I classify support in terms of how well you can resolve an issue and how fast you can resolve an issue. They don't reply fast enough. In a lot of instances, they don't get back to you immediately, and you have to wait for a while after creating a support ticket. They can be faster at that, but when it comes to resolving your issue, they are good. Overall, I would rate their support a seven out of ten.

Neutral

Prior to using RHEL, I was using Windows. I've also done a lot of work with Ubuntu, SUSE, and other Linux solutions, but Red Hat is the best one. I prefer it over other solutions because I'm used to it, and I find it better than other solutions. I'm used to the commands, and it is easy for me to navigate my way through it. If I have to choose between Windows and Linux, I would always go with Linux and choose RHEL because of its stability and agility.

I also use CentOS for my personal things or running some tests. For example, if I want to run a test with a client, it doesn't make sense to run a test in the client's production environment. I have a test environment with CentOS, and I run the test on CentOS before going to RHEL. I'm pretty comfortable using CentOS. CentOS is like my own testing environment.

The reason I switched over to RHEL was that over here, almost everybody or every client who uses Linux has RHEL. So, I had to understand how RHEL works. I realized that most people use it because of its stability. People find this system and its architecture good. A lot of clients talked about how they preferred the architecture of RHEL. Some clients find the commands to be easily readable, and some clients find it easy to integrate with others. A lot of clients find patching and package management pretty easy.

In terms of the deployment model, we have a private cloud. We have VMware for virtualization and Azure Stack for the private cloud. There are also public clouds, such as GCP, AWS, and Azure, and then there is the physical hardware. Some of our deployments are on physical hardware. So, we deploy RHEL on physical servers, and then, there's also the hybrid model when some clients want to integrate the private cloud and the public cloud together. They want the public cloud to be like a backup environment, or they want the private cloud to be a backup environment.

I was mostly involved in the deployment of the hardware and the private cloud.  I was also a part of the team that set up the hybrid environment, but I didn't do a lot of work on the public cloud side. The only complex part of the deployment was the hybrid configuration, where we were trying to interconnect the private cloud and the public cloud. The deployment on the public cloud was more straightforward than the deployment on the private cloud because, on a public cloud, the image is already there, whereas, on a private cloud, you have to set the image up yourself.

Each deployment model took approximately one week to deploy, but the hybrid model, requiring interconnecting the private and public clouds, took more than a week because there were a lot of dependencies.

In terms of maintenance, it does require maintenance. That's the main reason why people pay for support. 

We have definitely seen an ROI. There are around 15% savings.

It is pretty expensive, but it is worth it. Generally, in an enterprise environment, there is no cheap solution. This is coming from someone who is working with a company that provides a lot of solutions a bit cheaper than the industry standard. In the enterprise environment, I believe no solution is inexpensive, but RHEL is still pretty expensive.

Additional costs that I am aware of are usually for support and setup. A lot of banks use RHEL. I've seen the cost of the support and setup. Some of them complain about it, but they also talk about how well it works.

I have not compared the overall costs of open-source competitors to the overall costs of RHEL when it comes to supporting business operations over time. The only other distribution for which I have seen the pricing is AIX, which was a bit more expensive than RHEL.

I would always advise doing a proof of concept where the client gives out his requirements and you run a proof of concept based on those requirements to make them confident of purchasing the solution. It is always better if a proof of concept is done. This way, everybody knows what they're getting into.

Its built-in security features are definitely helpful, but at the end of the day, you have to go further than using the built-in ones. You have to do a few other things yourself. The built-in features are helpful for compliance, but we, and most enterprise organizations, always want to go further than using built-in features because some built-in features could be more open to risks. We use the best built-in features, but we always want to go further and integrate other features into the RHEL system.

I have used Red Hat Insights only once, and I have not worked much with it, but my colleagues handling monitoring used it. It was helpful for the unpatched system. They checked Red Hat Insights and saw the systems that need patching. We got an email saying that it is a security requirement and that we need to patch them because it may affect the security of the systems. Coincidentally, after doing the patching, we read blogs about security hacks out there for some of the older systems that were not patched early enough.

Red Hat Insights provide us with vulnerability alerts, but I am not sure about targeted guidance. Vulnerability alerts have impacted the uptime, which is something that we take very seriously. Uptime was one of the major reasons we wanted to work with Insights because we didn't want any attacks that would cause downtime.

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

I worked with different organizations. So, the use case varies from organization to organization. Right now, some of the teams are using it for applications like BI, and then there are a few others that are using it for Websphere, middleware, etc.

In terms of the version, most of them are on 7.9, but there are a few on 8.2 and 8.4 as well.

It enables us to achieve security compliance. Our security team is quite happy, especially in terms of patching up our servers, etc. It's compliant with our security requirements. With Windows updates, sometimes, there could be errors and the blue screen issue, and it could become hectic for the applications as well. Our security teams struggled a bit to update Windows, but when it comes to Linux, they are quite comfortable because they know that things will go smoothly.

I'm quite new to this organization, but I know that there has been improvement in terms of performance. We're using Red Hat Linux on Power Systems, which is quite different from the Intel platform. So, admins are much happier, and they are using it quite well now. Previously, we were using Windows for our applications, but now, we have made Linux mandatory for being open source and not bound to Windows. Things can be complicated on Windows. Especially when we're installing it, there are a lot of things, such as registries, but Linux is easier for admins. There is DVS as well.

When I worked in the banking sector, the most important part was user administration where you need to keep things under control for a specific user. The auditor usually looks for an agent or something like that, and it has been quite easy to manage things from that perspective. Things are more manageable now than in the past.

Windows operating system is used everywhere. You will find it everywhere, and every user is able to use Windows. If a user is using an operating system from the start, it becomes easier for them to use it when they come to a professional environment. That's an area in which I believe they need to put in extra effort, especially for the students. Currently, for their final projects, most students use Windows, and this is an area where Red Hat needs to put in an effort. They need to give some training to the students so that when they come to the professional environment, they're already used to it. It would then become easier for them to use it in a professional environment.

I'm also using IBM AIX, which supports a tool called Smitty. You just put Smitty, and you can do anything. At the backend, the command will run automatically. It is not exactly like a GUI, but you just give the input and it will give you the output. That is something that Red Hat should work on. That would be an added advantage with Red Hat.

It has been 12 or 13 years.

It is very stable.

We are mostly using VMware and Power Systems. Scalability-wise, they are always the best. We can upgrade to get all the resources on the fly. We never faced any issues. However, if you didn't add the required parameters on your profile on VMware or the Power System, then there is an issue, but that's not related to the OS. That's related to virtualization.

Application-wise, there are multiple teams that are using these systems. We have the database team, the middleware team, the MQ team, etc. There are also system admins. The system admins are the ones who are deploying it, but the owners of the system are different.

We have plans to increase its usage. Two years ago, we had only 60 or 70 servers of Red Hat, but now, we have 400 to 500 servers. Its usage is always increasing. After a year or two, we might end up with about 1000 servers.

We have contacted them a few times. We did ask the support team to get in when the cluster got stuck and let us know what's the issue and what's the solution. Whenever I have asked for support, they have provided the best support. I always count them as the best. We have never faced an issue with them. I would rate them a 10 out of 10.

Positive

We had Windows. The stability was the reason for switching to Red Hat. The stability of Windows varies, but Linux is quite stable now. That was the main part they were looking for.

We are very comfortable with using Linux. We have been using it for 10 to 15 years, and we can't switch to Windows. We can't use Windows even on our laptops. We are not used to using a mouse and GUI. The command prompt is much better for us.

We also use AIX because we have AIX infrastructure, but a few of the applications don't work on AIX, whereas they work with Red Hat Linux. That gives Linux an advantage. So, we use Linux on Power Systems, rather than AIX.

We have been working with different operating systems, and we also know most of the technical requirements, so it is easy for us. Usually, the OS installation takes a maximum of 25 minutes. If you are making extra file systems, such as for Oracle, it takes 10 to 15 minutes extra. A desktop or a single file system doesn't require much time. We already have scripts. We just run the scripts and everything is done by the scripts. Previously, it used to take two or three hours, but now, things have changed, and we're making life easier.

We deploy it ourselves. We don't ask other vendors to deploy it for us. In terms of maintenance, we have already been updating our maintenance contracts, especially the support contract. There are some old systems running in our environment, and we are in the process of upgrading those from version 6.9. We already have the required support.

There are four people on the team, but for Linux especially, there are only two people. We're easily managing 500 to 600 servers for Red Hat.

When you are running your infrastructure on this, you can always find some discounts with local support, etc. There are always some discounts to match your budget. It is definitely affordable. 

When it comes to virtualization, there are different factors. There is not only Red Hat. There is also IBM, VMware, etc. The third-party vendors always manage to come up with a good offer. Our company can't say no to that, and it works out fine.

We also have IBM AIX, and when you compare these two, there's a huge difference because IBM AIX's support is quite higher than Red Hat's.

To anyone interested in using Red Hat for the first time, I would definitely advise starting with the GUI because now, the GUI option is quite good, and you can do all the things. After that, you can slowly start moving to CMD. For learning, there are a lot of resources available online, such as YouTube and LinkedIn Learning, whereas Red Hat Academy is quite expensive.

The biggest lesson I have learned from using this solution is that when you're using the command line, you need to be extra careful. That's because when using the command line, a single slash can make a huge difference. That's what I learned at the start of my career.

I started with Red Hat Version 5. Now they have version 9, which I haven't used, but if I just consider the evolution from version 5 to 8, 8.2, or 8.4, there has been a huge difference because, at that time, people were scared of using Linux, but now, things are different. There has been a revolution in terms of OS. A lot of things are being changed, but in terms of the things that we do, for us, it is the same because we are doing system administration. As a system admin, there is nothing different for us. We are doing the same things again and again because the applications require the addition of storage.

There is also a change in terms of security features. If I compare the old versions with the new versions, in old versions, adding any exception in the host firewall was a real task, but now, things have either become smooth, or we have gotten used to it. Overall, for me, things have become easier. They are getting more and more secure, but with the vulnerabilities and the assessments that have been done, we need to keep updating. Now, everything has caught up with the latest security required in the market.

In our environment, we're using virtual servers. There are no physical ones. We are shifting to containers in my current organization. Most of the applications we are using are containerized, and it has been easy for us to manage those applications. However, we also require some in-built applications, and for that, a change in people's mindset is required. It's not about the OS; it's about the people who do the development. It is becoming a bit hard for them because they were using a different platform previously, and now, they need to move to the Linux platform. It is a little bit different for them.

Overall, I would rate it an eight out of ten. When comparing it with AIX, AIX is a bit easier in terms of use and it also has the Smitty tool.