Red Hat Enterprise Linux (RHEL) Reviews

Our company uses the solution for survey configurations across different types of databases, applications, and web servers. 

The solution has allowed us to stabilize our organization's environment. 

The solution is very stable, reliable, easy to use, and has good technical support. 

Some applications work better overall in comparison to how they work with other tools. 

Logs are detailed, stable, and consistent so it is easy to troubleshoot issues. 

Sometimes the solution deletes our archives or other features that were useful to us. We would like users to be surveyed before items are removed or be provided with a better explanation as to why removals occur. 

For example, some file system patches were recently removed but replacement patches do not cover all features. 

I have been using the solution for five years. 

The solution's efficiency and reliability are fantastic. 

We do not use security features or profiles much but have never had issues with them.

Technical support is great and I rate it a ten out of ten. 

Positive

We previously used Windows and Oracle but migrated some of those systems to the solution. 

The setup is straightforward from the operating system side. 

Installing applications and other software can be a bit complex because you need to first determine which packages are required. Once that step is completed, installation is fine. 

It is sometimes a mystery whether vendors support or license their products for a specific version of the solution. Generally, vendors are a few versions behind. For example, some do not support RHEL 8 and none support version RHEL 9. It is not easy, but the solution should work with big vendors and convince them to license new versions right away. 

Our company implemented the solution in-house. Deployment time depends on the application and use case. 

Two administrators handle ongoing maintenance which includes installing patch files. 

The solution's pricing is reasonable and it is less expensive than other products such as Windows or Oracle. Pricing was definitely an advantage for our company. 

We compared the solution to others we used and determined that price, ease of use, and its lightweight nature were benefits. 

Our company also uses Ansible because it works well with the solution. 

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 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 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.

We use Red Hat Enterprise Linux to host website content. 

The tool's most valuable features are stability and maturity. Linux offers cost efficiency. Red Hat comes at the top of other Linux vendors. I am very satisfied with Red Hat Enterprise Linux's maturity. 

We had issues migrating from the old to the new Red Hat Enterprise Linux version in the virtual environment. It forced us to spin up a new virtual environment to have the new Red Hat Enterprise Linux version. 

I have been using Red Hat Enterprise Linux for over 15 years. 

My experience with Red Hat's support team is positive. They are a lot better than our cloud CMS vendor. 

Positive

We used Sun Microsystems and Unix on on-prem. 

The product supports our hybrid cloud strategy well. 

We move workloads between different clouds and data sandboxes. 

Red Hat Enterprise Linux's knowledge base is quite extensive. It is free, which helps us to advocate the product. I would like it to continue and rate it positive. 

The Red Hat Enterprise Linux web console was helpful and offered visibility through dashboards. It helped us see what was going on with our system. 

I rate it a nine out of ten.