Red Hat Enterprise Linux (RHEL) Reviews

We use Red Hat Enterprise Linux as an infrastructure support operating system across both x86 and s390 platforms. Specifically, we are running it on x86 Intel and Linux s390 mainframe on Zynq.

Red Hat Enterprise Linux is a stable operating system. We recently upgraded the majority of our systems from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. We were able to automate most of the upgrade process and did not encounter any major issues. As a result, we were able to bring our systems up to date quickly and easily. This is a major advantage of using Red Hat Enterprise Linux.

From an automation standpoint, we have been able to automate some of our patching workflows. This has definitely saved us time and money.

From a security and compliance standpoint, it is easy to maintain compliance. This is mostly accomplished by patching Red Hat Enterprise Linux on a frequent basis. The availability of security patches is also quick, which allows us to keep up with our client requirements quickly. Red Hat usually does a good job of making fixes available in a timely fashion, so we can remediate high-priority issues when they arise.

From a containerization standpoint, Docker and Podman now give us the ability to move workloads and structures around with little effort. It is very flexible and consistent, and the results also provide us with a stepping stone as we move towards an orchestration platform like OpenShift. Our ability to run Podman on servers and then migrate those Podman deployments to OpenShift is very beneficial.

The most valuable features are ease of support and the ability to run a read-only course on the operating system.

Red Hat Enterprise Linux is easy to maintain. We currently use Red Hat Enterprise Linux 7 with Docker for containerization. With Red Hat Enterprise Linux 8, we are moving to Podman, which is a native container runtime that is part of the operating system. 

I suggest that Red Hat move to a continuous delivery model instead of major releases. I know that this is a trend for many middleware products. We do not have a major release network. We only have monthly or quarterly roll-on releases on our continuous delivery model, which reduces the impact of a major version. This would probably be the easiest change to make.

The technical support has room for improvement.

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

Red Hat Enterprise Linux is stable.

Since we run a number of hypervisors for all of our real systems, I believe that a lot of the scalability comes from a level higher than the operating system. However, Red Hat Enterprise Linux can accommodate these tools.

Red Hat support could be improved, and they should have a better relationship with IBM and VMware. This is because a lot of what we do involves working with IBM, both from a hardware standpoint and from a hypervisor standpoint. We have a long history with IBM, and we are now starting to work more with Red Hat on OpenShift private cloud solutions and other tooling. However, Red Hat and IBM are not on the same page. They are still very different companies, and they don't always know what the other one is doing. This can lead to contradictory information, inaccurate information, and frustration for customers. I think there is a relationship between Red Hat and IBM that could be improved. If Red Hat and IBM could work together more effectively, it would put customers at ease and make them more confident that they could get the work done. It would also help IBM and Red Hat to better understand each other's products and services, which would lead to better customer support.

For example, we recently had an incident that started as a severity two on the scaling. A number of our account representatives called and emailed us, saying, "Hey, we wanted to let you know that you have an open case. We need some help with this." The incident was not a production outage, but it was preventing us from doing something, so there was an indirect production impact. After about ninety minutes of back-and-forth communication, we were told, "Okay, go ahead and bump it up to severity one. That should get traction." We did not hear from anyone for four hours. This does not happen every time, but in this case, it needed to be dealt with well before four hours. It made things more difficult than they needed to be. Sometimes the support is an eight out of ten, and sometimes it is a four.

The end result was still good because they acknowledged what happened and got everyone together to resolve it but it was not done in an efficient way.

Neutral

The initial setup of Red Hat Enterprise Linux is very straightforward. It is not much different from any other Linux operating system. Most of the things we need to consider when deploying Linux are relatively standard. Therefore, Red Hat Enterprise Linux is easy to deploy and maintain. If we know how to administer Linux operationally, then Red Hat Enterprise Linux should be easy to deploy.

I do not know enough to give a comprehensive answer, but other operating systems are in use at my company because they have more favorable licensing terms. This is a major factor in why we do not use Red Hat Enterprise Linux everywhere.

We evaluated SUSE Linux Enterprise and a few others. Depending on the computing platform, it is sometimes better and sometimes not. For some of our environments that are running on s390, SUSE Linux Enterprise gives us a better price point. However, for some of our other environments, such as x86 on VMware, it is more valuable. It is a better financial move for us in those cases. Therefore, the value of SUSE Linux Enterprise changes depending on the computing architecture.

I give Red Hat Enterprise Linux a ten out of ten.

We have a requirement to have a Linux operating system.

I'm not sure how our developers are building their images. I believe they use some desk start products.

We use SUSE Linux Enterprise for Linux on the mainframe. In a particular enclave, we have some government contracts where we use Red Hat Enterprise Linux for a number of reasons, including licensing for hosts. These hosts are hosted with OpenShift. We use Red Hat Enterprise Linux for all our Bastion hosts and OLS for our other hosts.

The Red Hat knowledge base is generally an eight or nine out of ten, but it can be difficult to get the information we need. The initial level of support is a six or seven, but it improves as we escalate the issue.

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.

Most of the applications I work with, including our primary enterprise-level application, necessitate the robust capabilities of an enterprise-grade operating system. Therefore, we utilize Red Hat Enterprise Linux to ensure optimal performance and stability for these demanding applications.

Red Hat Enterprise Linux is praised for its exceptionally precise documentation, which greatly aids in the learning and implementation process. Troubleshooting is straightforward, and solutions to any arising issues are readily available through a simple Google search.

For provisioning Red Hat Enterprise Linux, tools like Terraform and Ansible are commonly used to automate the process on a base machine. While Terraform handles various provisioning tasks, Red Hat provides its software for patching, although OpenSCAP is also a strong alternative for effective patch management.

Our organization uses Red Hat Insights, leveraging its user-friendly single dashboard to monitor all aspects of our systems. This centralized platform has proven invaluable for maintaining an overview of our infrastructure and ensuring operational efficiency.

We often use the Red Hat Enterprise Linux web console for things like viewing system performance and logs, managing user accounts, and configuring network settings.

Red Hat Enterprise Linux is robust, stable, and well-documented compared to the open-source versions of Linux.

I find the most valuable aspect of Red Hat Enterprise Linux to be its ease of customization. The operating system allows for the simple addition of kernels, modules, and other applications, making it highly adaptable to various needs.

Red Hat has several areas ripe for improvement. In the Asia Pacific region, where cost-optimization is highly valued, Red Hat's support and subscription costs are perceived as high and could be reduced. While their security documentation is comprehensive, some solutions lack open-source availability or training resources, unlike platforms such as Ubuntu. Furthermore, the quality of documentation and training sessions, particularly for OpenShift, could be enhanced. Addressing these issues would strengthen Red Hat's offerings and better serve its customers.

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

Red Hat Enterprise Linux is extremely stable.

When Red Hat is involved in virtualization or OpenStack, moving from one virtualization platform to another becomes easier. However, when scalability is needed, it depends on the underlying infrastructure security, which is part of Red Hat import.

Communication quality is very good. I find very helpful people in the support section, and the Red Hat portal is robust for main solutions and support. When I receive support, I often find very interesting solutions.

Positive

I previously used CentOS, Ubuntu, and Debian, among other Linux distributions. However, with the growing popularity of containerization technologies like Kubernetes and Docker, solutions like Red Hat OpenShift are becoming increasingly common, particularly in regions like Bangladesh, India, and the Asia Pacific. That is why we are using Enterprise Linux.

The initial deployment and migration of Red Hat Enterprise Linux are straightforward, particularly for cloud-based solutions. However, on-premises migrations present a slight challenge due to the complexities of CVS solutions and potential application compatibility issues. This can involve numerous parameters that require careful consideration. My lack of experience with Red Hat's migration tools may have also contributed to the perceived difficulty.

Red Hat could gain a competitive advantage in the Asia Pacific region by adjusting its pricing strategy. Lowering the cost of enterprise-level offerings could attract organizations seeking operating systems or Kubernetes solutions, as these tools are essential for many businesses in the region. This adjustment would make Red Hat a more appealing choice compared to competitors with potentially higher pricing.

I have not found another operating system that matches Red Hat Enterprise Linux; it receives a perfect score of ten out of ten.

The Red Hat Enterprise Linux upgrade process is generally smooth. However, patching occasionally causes issues, typically due to application incompatibility or bugs in the updated packages. This necessitates restoring from a backup to maintain functionality. While this is a recurring problem, the infrastructure itself remains stable throughout the process.

We are part of the State Department and use the solution to achieve operational excellence and readiness for the cloud. We think about what the next 20 to 30 years of consular systems infrastructure might look like to build and design for the next 40 years. Not many other companies think beyond a decade. 

The solution was implemented in our environment in 2014. The initial mission is still the same but how we go about it is different. For now, the solution is more for application support and making sure we are following State mandates or executive orders. 

For example, one use case involved planning, designing the implementation, and executing a launch of online passport renewals.

Our environment is moving toward tools that provide automation to remove human error. These are tactical operations and use cases. We currently use SaaS, OpenShift, and Ansible to a limited degree.

We had many issues with staff turnover during COVID. Working from home and trying to maintain databases was not ideal. During this time, the solution would have been rated a five out of ten.

Sometimes, vendors provide the government or bigger organizations with band-aids but not solutions. Everything seems to be a problem so many fixes are provided. A fix for this or a fix for that is equivalent to putting a band-aid on a large cut which will not work. Vendors tend to look at the money game because larger companies are their bread and butter. There should be an appreciation for the needs of bigger organizations.

It took some time to get us in a good position with the solution. There is definitely some growth and appreciation. We are at a place now where we can grow our environment. Today, the solution is rated a seven out of ten.

The solution is useful for application support and automations. 

A completely new setup should not be required when upgrading to a new version of the solution. For example, moving from RHEL 7.7 to RHEL 9 requires us to go through every minor version upgrade as well as RHEL 8. We do not have the ability to patch as quickly as we would like, but there are pathways. We got on 6.8 this year and migrated to 6.11 where we are trying to work on the automation portions of deployment. Before, we had variations of versions 7.2, 7.3, and 7.5 in our environment. We have not yet been able to use the supported versions that we are accustomed to with our applications. We are now on 7.9.1 and are trying to implement the minor upgrade versions in our environment. We have not yet experienced a healthy environment or the joy of using RHEL because we keep encountering issues and problems.

There are issues when upgrading or integrating with previous applications or systems such as Satellite, vRA, SaaS, or OpenShift. This is extremely, extremely important because a lot of our infrastructure is on RHEL. We need to have someone onsite to adjudicate our infrastructure's most important applications, when we would rather be able to patch them in a timely manner without having the whole world assist us. 

The solution should be more user-friendly so we better understand how to scale. It is not that we shun professional services, but there is a major knowledge gap in our understanding of the solution. 

I have been using the solution for four years. 

With anything, when you nurture it things work. Now that we are finally on 7.9 and migrated 6.11 we are actively trying to automate. This puts us in a better and more stable position. 

We rely primarily on our contracting staff or professional services for support. We receive onsite support from account engineers who apply critical patches or troubleshoot code that is not cohesive. For the most part, turnaround time is moderate but certain legacy applications are harder to troubleshoot, so they take more time.

Technical support steps in for big issues and provides good help. For example, support assisted with decommissioning 6.2 and 6.5 because they were at end of life with no option for purchasing ongoing support. We had professional services and many different products, so technical support made an exception to help with migrations and that was appreciated. 

Technical support is rated a nine out of ten. 

Positive

I do not know the setup details. The solution was implemented in 2014 and I joined the team in 2018.

We are currently experiencing issues when upgrading or integrating with previous applications and are looking for solutions. We push out patches and look at Tower. We already tried Puppet and it integrates with Satellite, but we prefer to use home-grown products. 

Because we use Satellite, it would be nice if the automation portions come from Tower or others. We have explained this to an account manager but solutions are being presented to us from a sales perspective. For example, we are told that we should ramp up, get other applications, or purchase more licenses.  

Decommissioning is one of our biggest issues. We upgrade and spin it up, but then have problems decommissioning some applications so more user licenses are required. For example, we have an unused server but cannot remove the license because we are either unable to get assistance or do not know how to perform the action.

We used vRA with the solution but it did not work for us.

We also used CloudForm but are attempting without success to decommission because it was not a useful case.

It is important to ensure there is a level of training for implementation. You need to understand compliance for your organization to determine whether vendors can provide appropriate tools. 

Do not be afraid to ask questions once the solution is implemented in your environment to ensure you are where you need to be. 

Stay on top of version or patch releases to prevent bugs or security vulnerabilities to your ISSO or agency. 

I rate the solution a seven out of ten. 

Our primary infrastructure operating system is Red Hat Enterprise Linux, predominantly RHEL Eight. While some products utilize RHEL Seven, RHEL Eight point Zero is the standard for most of our operating systems and servers. However, server choices may vary based on specific industry requirements. Our underlying infrastructure relies almost exclusively on Linux distributions.

Our primary Linux installations use Red Hat Enterprise Linux in an on-premises VMware environment, with some instances deployed on AWS.

The built-in security features simplify risk reduction by allowing direct control of the root system's access.

Red Hat's knowledge base is excellent.

While Red Hat Leapp and Insights are helpful tools, they are not part of my daily workflow.

The web console is a good feature.

Red Hat Enterprise Linux enhances uptime and security, boasting faster boot times than other operating systems.

The most valuable feature of Red Hat Enterprise Linux is its security, which is more secure than Windows. 

Integrating certificates from third-party clients into Red Hat Enterprise Linux can be challenging due to the operating system's stringent security policies.

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

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is scalable.

The technical support team was professional and quickly resolved our issue.

Positive

We use Oracle for our database, Ubuntu in our testing environment, and Red Hat Enterprise Linux in our production systems due to its increased stability.

The cloud migration from Red Hat Enterprise Linux Seven to Eight was straightforward due to the absence of underlying infrastructure complexities. However, the on-premises migration presented challenges from existing infrastructure dependencies, resulting in numerous errors.

The migration of approximately 200 servers required a team approach to ensure continuous monitoring. Although two people could have completed the migration, a four-person team completed it within two days. 

The migration from Red Hat Enterprise Linux Seven to Eight was done in-house.

Red Hat Enterprise Linux offers a compelling value proposition for corporations due to its robust support infrastructure, which is essential for maintaining enterprise-level systems. However, the pricing model may be less attractive to individuals or small businesses. Compared to cloud-based platforms like AWS or Azure, which offer flexible pay-as-you-go options, RHEL's subscription-based model can become cost-prohibitive for those with limited budgets or smaller-scale projects.

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

We utilize Ansible to provision and patch our extensive server infrastructure. Ansible's automation capabilities enable efficient batching and management of security patches across all servers.

We test all the patches for some time before we add them to our production environment.

We utilize Red Hat Enterprise Linux in our private cloud and on-premises environments, but I've observed better performance in the cloud, likely due to the greater availability of resources.

Red Hat Enterprise Linux does require maintenance.

I provide consultation to clients for their mission-critical applications. Its primary use case is running containers and microservices on Springboard.

My customers use versions 7.2 or 7.3. I have used versions 8.2 and 8.4. I have tried version 9, but I use version 8.4 specifically because it supports HighPoint RAID for storing the data, whereas the client applications run on the much lower version.

There are benefits in terms of price, security, and stability to reduce the risk of applications going down or something like that. A vast majority of systems are on Red Hat Enterprise Linux than on other distributions, which is another benefit.

Red Hat Enterprise Linux helps to achieve security standards certification. They use it in the PCI DSS segment, so it enables the applications to be compliant with all these security aspects.

Red Hat Enterprise Linux is very stable. It has been in the market for many years, and it is used by large organizations.

Their documentation and knowledge base are valuable. As an individual developer, whenever I have problems, it is easy to find the information. Their knowledge base is seamlessly integrated with the software. Whenever I have a question, it directly takes me to the knowledge base. It is well documented.

It supports scripting very well. Everything is scripted. A snapshot is taken in the VM, and the script is applied. It lends itself to better security and governance processes.

Its installation on a RAID or cluster system is something difficult. There are specific teams working on that. The GRUB configuration is also a little different from the other Linux distributions. 

In terms of additional features, as technology keeps evolving, the product will also have to evolve. For example, Microsoft Windows has come a long way. In Windows 11, there are so many features that are fundamentally the same as the oldest version, but there are other aspects or processes that have improved. macOS has also evolved over time. Similarly, in the Red Hat Enterprise Linux that I used in 2003 and the one that I am using now, some things are the same and some things have changed. Red Hat can continue to engage clients, understand the use cases, and update them.

I have been using Red Hat Enterprise Linux since 2002 or 2003. Red Hat has a vast variety of products. I have only been using Red Hat's operating system. I have not used Red Hat's other products.

It is very stable.

It is scalable, but I do not have experience in building hundreds of systems on a VM.

I have not used their technical support at all. I only use their documentation portal for self-support. Our production support team interacts with Red Hat's support team.

As a developer, I use both SUSE as well as Red Hat Enterprise Linux. My personal preference is Gentoo, but no one runs Gentoo on a production system. Gentoo is better in terms of customization. You can choose what you want.

I am not directly involved in its deployment, but I am planning to build an application. At that time, I will be deploying it myself. In the organization where I work as a consultant, there is a segregation of roles. There is a production support team, there is a development team, and there is a DevOps team. I am a part of the development team.

Its initial setup is straightforward. It is not complex. It also depends on the architecture, high availability, etc.

In terms of deployment, earlier, it was on-prem, but now, it is on the cloud. My client runs about 150 VMs on the cloud in the production, staging, and QA environments. Most of the things have been consolidated into VMs. The migration is complete. It was not that complex.

I have not measured that, but it should pay back for itself easily. The ROI should be reasonable. The cost over a period of time should be minuscule. As compared to other OSs, it is better to go with a big, known, and trusted vendor.

As a developer, I pay around 10,000 Yen, which is around $100 per annum for support. SUSE and Red Hat are typically the same without standard support. The pricing is not a big deal. Enterprise customers will pay for the support. Enterprises have the money for one or two products like this that are reliable and supported.

As a consultant, I advise customers to go for support. You mitigate risks by having support. For your personal usage, you can manage without support, but when it comes to the enterprise level, you need to delegate things to people, and it should be through the proper channel. You need a proper point of contact.

I would advise following the best practices recommended by Red Hat. It will minimize the downtime of the application or system. Partner with the vendor and get that support. Know the business case and build a strong relationship with the vendor. Trust them and tell them your use case, and they will come up with the best solution possible.

I am not a big authority on Red Hat or other Linux or Unix products. Only recently, I have been exposed to the concept called hardening and penetration testing. I do not know whether Red Hat provides a hardened version of the OS. My basic distribution is Gentoo which provides a hardened version of Linux. On the client side, the organizations we work with have different departments, such as the security department and the compliance department. For security, they work with various options that are available. For penetration testing, we engage a penetration testing consultancy company once a year.

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

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 Red Hat Enterprise Linux servers and Satellite for patch management. We're also using Ansible for automation and hardening. Additionally, I'm doing a migration project from RHEL 7 to RHEL 9. Our environment is a mixture of on-prem and cloud systems. We are a hospital, so we can't keep some information on the cloud for compliance reasons. 

We have a separate team for the hybrid, and I'm part of that team. We've been migrating a few servers from on-prem to the cloud. Everything used to be on a hardware server, but now we use the cloud for the storage network. We share workloads between the cloud and the physical data center. Our Rubrik data backup archives to the cloud with Microsoft Azure. We also partner with Pure Storage, which we use for on-prem storage.

We have physical Red Hat Enterprise Linux servers for the Splunk environment, which is the security solution we use. Hadoop went to the cloud, but it used to be on Red Hat Enterprise Linux. We have VMware, and our VMs are reserved for Red Hat Enterprise Linux.

We have been using Red Hat since I was hired. All the app owners want Red Hat. Red Hat Enterprise Linux supports SQL and Oracle databases, which is helpful.

Red Hat Enterprise Linux has made significant improvements in terms of storage. You can mount an 18 terabyte file system. It also supports NFS shares and the SIP share for the photos. There have been many features added since RHEL 6. It's more user-friendly and graphical. 

We use Ansible as a go-to for provisioning and hardening the servers. It's so much easier with Ansible because we used scripts in the past. We had to log into each server as such, and it took a long time. With Ansible, we just run one playbook, and it takes care of everything. 

I used Leapp for my upgrade from RHEL 7 to 8. It's an excellent utility tool. When I run the Leapp script, it tells me everything I need to take care of before I run a migration. Red Hat Insight is good because it tells you about the future patches available. 

We use Red Hat Enterprise Linux image builder. Our golden image is a real image. We harden it, and it's our golden server. When we need a new VM, we can just make a snapshot of that. If it's a physical server, then I have to do it manually.

AIX will be out of support in the next few years, so that is a problem because a lot of the clinical apps use AIX. 

I have used Red Hat Enterprise Linux since I started working at this hospital six years ago.  

I rate Red Hat support eight out of 10. It's helpful when we face hardware issues, kernel panics, or the server is hanging. We always open a support case with Red Hat, and they're helpful at every level. It used to be in the United States, but now they outsource everything to India, so there is a big time difference. That's the only issue. 

Positive

We have always used Red Hat, but they use CentOS for a few applications. Most are using Red Hat. Another team uses Microsoft Windows 2016. It's a different team. The application team decides which one they prefer, but most clinicians use Red Hat Enterprise Linux servers.

The application owners like Red Hat instead of CentOS or another flavor of Linux because the support is reliable. If something breaks, they can call Red Hat support. It's the enterprise standard Linux.

I do the Red Hat Enterprise Linux upgrades. It's straightforward because I can just run Leapp to upgrade it

I rate Red Hat Enterprise Linux nine out of 10.