Our main use cases for Red Hat Enterprise Linux (RHEL) currently involve general server workload, including numerous Oracle-based workloads.

The features of Red Hat Enterprise Linux (RHEL) that I appreciate the most include the most recent iterations such as no-downtime patching, live patching, and the ability to snapshot or snapshot LVM's; these features are more of a Linux capability, however, they have been really beneficial to us. 

High availability has been extremely beneficial for us to support. These features benefit our company by providing less downtime. We are not taking downtime to do patching on tier-one systems, and we spend less manpower and time to perform the types of automation and management that would normally take considerable time to accomplish hands-on, resulting in significant time savings.

Security requirements are always a consideration in choosing Red Hat Enterprise Linux (RHEL) in the cloud. Anytime we make any decision, security is definitely one of the foremost considerations we have taken place.

The biggest thing we look for is the ability to abide by STIG, as we do, and then apply our NIST policies as well as our defined HIPAA policies; Red Hat Enterprise Linux (RHEL) makes that a really easy process through the automation aspects.

We manage our Red Hat Enterprise Linux (RHEL) systems for provisioning and patching using a combination of VMware vRealize for actual deployment, and then we use Ansible Automation for the day-two configuration and lifecycle. Once software deployments and configurations are all Ansible automation, it couldn't work any better for us. As long as you have a coding background and understand YAML, Ansible works fantastically.

If I had to suggest one improvement for Red Hat Enterprise Linux (RHEL), it would be clearer licensing information. There could be easier licensing paths for Red Hat; currently, it's included with many different things, yet just more clearly defined skews would help. That's the main consideration.

We have used Red Hat Enterprise Linux (RHEL) for a total of about a decade now.

Regarding stability and reliability, our experience is that we don't have to reboot our Red Hat Enterprise Linux (RHEL) servers as we do with Windows servers every 90 days for something bad. 

We only have to reboot our Red Hat Enterprise Linux (RHEL) servers for updates or some unusual code push. We can count on Red Hat Enterprise Linux (RHEL) just as we can count on Cisco UCS.

Red Hat Enterprise Linux (RHEL) scales fantastically with the growing needs of our company. We have clustered our Red Hat Enterprise Linux (RHEL) servers, and as far as size, they far outweigh anything else in the environment. 

Our largest clusters run on Red Hat Enterprise Linux (RHEL), and we continue to see that as we grow, it is able to grow with us.

I would evaluate the customer service and technical support of this solution as being excellent when we need them. 

The information in the knowledge base is so readily available that we don't very often have to contact customer service, however, when we do, they are generally very knowledgeable and well-versed in our size.

Positive

Before we chose Red Hat Enterprise Linux (RHEL) for the first time, we were mostly using Windows. Red Hat Enterprise Linux (RHEL) was really our first enterprise Linux that we brought into the environment under the enterprise scale.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the manpower; it's the ability to automate significant management tasks. That is the biggest ROI on the amount of time we spend managing this system, as we can take that time back and dedicate it to other types of innovation.

My experience with Red Hat Enterprise Linux (RHEL)'s pricing, setup costs, and licensing has been pretty consistent, and honestly, compared to the rest of the market, it's pretty fair.

We've certainly considered other solutions before choosing Red Hat Enterprise Linux (RHEL), including open source; we do use a bit of open source such as Rocky Linux, which most are going to be Red Hat derivatives. We also looked into other options, however, for anything tier one or most tier two, our current tier-one environment is Red Hat Enterprise Linux (RHEL). From a stability and supportability standpoint, Red Hat Enterprise Linux (RHEL) is a clear winner.

Currently, I can't say that Red Hat Enterprise Linux (RHEL) necessarily supports our hybrid cloud strategy; what it does do is make the deployment of several deployments and conception models much easier for us to consider versus having to do custom imaging for our cloud presence. 

It helps us bring down the amount of time it takes us to deploy.

On a scale of 1-10, I rate Red Hat Enterprise Linux (RHEL) an 8.

My use cases for Red Hat Enterprise Linux (RHEL) include doing OpenShift tasks and general Linux use cases.

The feature of Red Hat Enterprise Linux (RHEL) that I value the most is automation. Automation saves time for me as I don't have to keep doing the same tasks repeatedly. My company benefits from automation in Red Hat Enterprise Linux (RHEL) since we use Ansible to deploy numerous operating systems. 

We can initiate 20 deployments, and they get configured automatically, which is efficient.

Red Hat Enterprise Linux (RHEL) might have helped to mitigate downtime and lower risk, though I cannot think of a specific example.

Improving Red Hat Enterprise Linux (RHEL) is a challenging question. Regarding SELinux, they could make that clearer or make it easier to use.

I have been using Red Hat Enterprise Linux (RHEL) for about a year.

The stability and reliability of the Red Hat Enterprise Linux (RHEL) platform are really amazing. There are many instances where I'll have an Active Directory server go down, and I go into the remote consoles because Windows is doing forced updates, and it drops, which is extremely annoying. I haven't experienced any similar issues using RHEL.

Evaluating how Red Hat Enterprise Linux (RHEL) scales with the growing needs of my company is challenging because much of what I do is lab work, so most projects are not scaling out. They remain at a set scale, then get torn down, and we create another one at that same scale.

I've had limited experience working with Red Hat support. 

I submitted a ticket because I was trying to access training material since we were a partner and were supposed to get it free, however, I had an issue with my account. 

I opened a ticket, and the person who took it responded in 20 seconds and fixed it immediately, which was excellent. I would rate the customer service and technical support of Red Hat Enterprise Linux (RHEL) at a ten out of ten. It was extremely fast.

Positive

I'm not certain if Red Hat Enterprise Linux (RHEL) is the first solution of its kind that our company is using.

Most of my management of Red Hat Enterprise Linux (RHEL) systems for provisioning and patching is done in labs, so I don't see many persistent workloads. Most systems get torn down. I haven't done much patching, but I'm familiar with Cockpit, and I have personal VMs that I manage that way.

When upgrading from RHEL 8 to RHEL 9, we encountered some issues and had to use a leap utility for jumping between releases. Once we found the documentation, the process was straightforward.

Since we operate in a lab environment, instead of upgrading Red Hat Enterprise Linux (RHEL), we typically download the newest release.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL) from my technical perspective is automation. I use automation daily to provision VMs and other systems. You can initiate the process and focus on other tasks while it runs, which increases efficiency.

I get our licensing for Red Hat Enterprise Linux (RHEL) through our account team, so I don't handle that aspect.

We did not consider other solutions to my knowledge before choosing Red Hat Enterprise Linux (RHEL) since Ansible is ubiquitous in our environment.

I would rate Red Hat Enterprise Linux (RHEL) overall as a nine. There are some inconsistencies with commands, since it's built upon years of development, some legacy commands remain with opposite rules compared to newer commands. If it were more consistent, it would merit a ten.

Our main use cases for Red Hat Enterprise Linux (RHEL) at our company involve it being our primary operating system for most of our servers. We're about 80% Red Hat Linux, 20% Windows.

The feature of Red Hat Enterprise Linux (RHEL) I appreciate the most is the ability to build images from the Red Hat pipeline, which is very effective. 

We also have an on-prem image management system that works really well with Red Hat. These features of Red Hat Enterprise Linux (RHEL) benefit our company since they allow us to perform life cycle tasks faster.

Our upgrade or migration plans to stay current with Red Hat Enterprise Linux (RHEL) are that our operating strategy is to put all net new on 8.10, and we are going to stay on 8.10 until 9.10. We typically just stay on the long-term release.

As for how Red Hat Enterprise Linux (RHEL) can be improved, besides being cheaper, I am uncertain. From a technical perspective, everything is addressed, which is part of the reason why we have as many systems as we do. It's probably one of the reasons why we moved away from SUSE Linux all those years ago, and cheaper pricing would definitely be beneficial.

I have been using Red Hat Enterprise Linux (RHEL) for approximately ten years. I've only been with the company for three years, and Red Hat has been there since before I arrived.

Regarding stability and reliability, we haven't had any issues with Red Hat VMs crashing due to a Red Hat issue.

Red Hat Enterprise Linux (RHEL) scales with the growing needs of our company quite effectively, as we're still on-prem and a VMware shop, so it functions seamlessly. Many of our applications scale really well, with some having several hundreds of VMs, which we couldn't accomplish on Windows.

The customer service and technical support experience is good. We have many highly qualified senior tenured engineers with Red Hat, so there are very few instances where we need to call somebody for assistance. It's usually account-related or access-related, not normally technical issues.

Historically, we used SUSE Linux before choosing Red Hat Enterprise Linux (RHEL).

Our architecture doesn't get hands-on. We guide and influence, so we have done upgrades over the years. We've done upgrades on upgrades on upgrades over the years. We typically don't do cross-version migrations if we can avoid it. It's a lot cleaner to do migration from major revision to major revision.

From a technical perspective, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is that compatibility and supportability are easier to adopt. There's a wider range of things that support it, and it has a larger community for getting support compared to Windows. From a server perspective, it functions better, and there are better capabilities for getting things to work and supporting any issues that might occur.

I'm not involved in the pricing, setup costs, or licensing for Red Hat Enterprise Linux (RHEL). I hear that it's expensive, but everything is getting expensive these days, so I don't think it's Red Hat specific. VMware's kickoff after the Broadcom acquisition has created a catalyst for everybody to increase their prices.

I haven't considered changing to other solutions since CentOS went their own route. For the most part, everything is Red Hat for us. It just depends on the capabilities that determine what version we run. 8.10 is the standard, but before eight, we would have several instances on 7.5, 7.3, depending on the features and capabilities the application needed. If it was just a generic application without special requirements, we usually put them on the latest version.

When it comes to managing Red Hat Enterprise Linux (RHEL) systems regarding provisioning and patching, we are moving to Ansible. We are on VMware's vRealize operations and orchestration, and we are moving all of our management and deployment strategies to Ansible. We are transitioning to Ansible since we have so many different systems and ecosystems that we need to touch; having one platform rule them all makes it easier for life cycle management and deployment. Ansible allows us to do everything in one seamless pipeline versus having to run five different automations for standing up a VM, standing up storage, and creating firewall rules.

I'm not very familiar with Red Hat Enterprise Linux's (RHEL) built-in security features when it comes to simplifying risk reduction and maintaining compliance. Cybersecurity requirements are abstracted from us, and they have their own tool suites, but we do have integrations with Red Hat. We use CrowdStrike, Carbon Black, and Rapid7, and all of those tools have integrations or abilities with Red Hat, so we leverage those tools but nothing is necessarily native to Red Hat.

Red Hat Enterprise Linux (RHEL) has not helped to mitigate downtime and lower risks any more than any other operating system. The contributing factors of downtime are typically external, whether it's power or networking or storage. In our ecosystem within a Red Hat space, crashes are very infrequent and usually something external.

On a scale from one to ten, I rate Red Hat Enterprise Linux (RHEL) an eight.

Our main use cases for Red Hat Enterprise Linux (RHEL) include our shift from VMware Tanzu container platform to OpenShift container platform about three to four years ago. We are also starting to use the Ansible platform to automate some networking.

One of the main benefits was that we were able to integrate with Github and minimize deployment to minutes versus days. 

The feature of Red Hat Enterprise Linux (RHEL) that I find most valuable is the Ansible automation platform, which is very user-intuitive, and there is abundant documentation and guidance available. 

Red Hat Enterprise Linux (RHEL) helps us resolve many automation issues that we are facing now, as we attempt to automate setups and restore through Git and integrate with GitOps. It is working for us, and we are still in the deployment phase. We have been working closely with Red Hat, and it has been effective.

Currently, I don't have any specific improvements in mind for Red Hat Enterprise Linux (RHEL). One of the tools I'm examining is the automation platform, and it appears there is still room for improvement since it is relatively new. Red Hat is working on this, and it will improve, though there are some bugs present. 

To make Red Hat Enterprise Linux (RHEL) a perfect ten, improvements could come from newer features and software additions, such as Ansible. They are transitioning from Galaxy to the automation platform, which is new and has some issues, but this is expected. As the platform matures, it will continue to improve.

I have been using Red Hat Enterprise Linux (RHEL) for approximately three to four years.

Red Hat Enterprise Linux (RHEL) is very stable. We have been running it for approximately three to four years as our main container platform, and support is excellent. We can get people on the phone, and the response time is great. We haven't had to address any major issues.

Red Hat Enterprise Linux (RHEL) scales excellently with the growing needs of my company. It is easy to scale. With our OpenShift platform, downtime is close to zero when it comes to upgrades or scaling, and it is very easy for us, especially when integrating with GitHub.

The customer service and technical support for Red Hat Enterprise Linux (RHEL) are very responsive. I would rate them a nine out of ten.

Positive

We are deploying Red Hat Enterprise Linux (RHEL) on-premises. I have been involved in many Red Hat Enterprise Linux (RHEL) upgrades or migrations to on-premises, and it is straightforward. The documentation and how-to guides make it very simple.

The biggest return on investment when using Red Hat Enterprise Linux (RHEL) from a technical perspective is minimal downtime for end users.

Red Hat Enterprise Linux (RHEL) is superior to other solutions I've used in the past, such as VMware, primarily due to cost savings, which was our main reason for migrating.

When managing Red Hat Enterprise Linux (RHEL) systems regarding provisioning and patching, we use a cluster environment, so everything is cluster-based, and we use GitHub to perform upgrades and patches almost seamlessly with no downtime. 

Our upgrade and migration plans to stay current with Red Hat Enterprise Linux (RHEL) involve upgrading our clusters. Red Hat Enterprise Linux (RHEL) has helped us to mitigate downtime and lower risk with zero downtime achievement. 

I rate Red Hat Enterprise Linux (RHEL) an eight out of ten overall, as I am still relatively new to it on an enterprise level, having previously worked on standalone systems.

My main use cases for Red Hat Enterprise Linux (RHEL) are mostly just running applications, web servers, app servers, databases, etc.

I don't have a preference on features of Red Hat Enterprise Linux (RHEL), as I appreciate many of them. While just getting into cloud, I'd say the best feature is YUM, DNF, and related tools, which are simple and easy to use and manage. 

The simplicity of Red Hat Enterprise Linux (RHEL) benefits my company in general since we're under many audits and regulations that allow us to track any discrepancies we may find in the reports, as to remediate those vulnerabilities and apply the necessary patches so that we can be compliant with our systems.

Red Hat Enterprise Linux (RHEL) helps me solve pain points through vulnerability management, and its Satellite has been a really good tool to help us track vulnerabilities as well as patching the server.

We are hybrid, so we deploy Red Hat Enterprise Linux (RHEL) both in the cloud and on-premise. For our cloud needs, we use both Azure and AWS. We have a good track record with Red Hat Enterprise Linux (RHEL) and security, due to their ability to produce Day 1 patches, quick responses, and great customer support when we face problems.

When it comes to provisioning and patching, we usually manage our Red Hat Enterprise Linux (RHEL) patching in a monthly cycle, using Ansible to help update our monthly downloads from Red Hat Enterprise Linux, move it to our satellite, and then push it out to our servers.

Red Hat Enterprise Linux (RHEL) supports our hybrid cloud strategy. We mostly use both Windows and Red Hat, making it our primary Linux operating system for applications, and we've been using the Red Hat images that we've created for cloud, deploying them there with the necessary utilities and applications.

I assess the knowledge base offered by the Red Hat Enterprise Linux (RHEL) system fairly positively, especially for support questions, however, the only issue I have is that often, you have to log in with your provider ID; in some cases, I understand. That said, there are others that are not just generally support specific to Red Hat, which is a problem.

Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risk through our ability to patch quickly, with relatively fast reboot times, and the amount of changes applied that don't affect systems much, especially with patching, so everything works as designed with very little incompatibility issues.

Red Hat Enterprise Linux (RHEL) can be improved by offering more on the Ansible side, with more integration with Ansible Satellite and all their tools for a one-stop area that manages both vulnerabilities and image deployments in a workflow pipeline.

I have been using Red Hat Enterprise Linux (RHEL) since Red Hat 4, which was a long time ago.

Its stability and reliability are fair and stable, with not too many issues encountered as long as no one is messing with the kernel configuration.

Red Hat Enterprise Linux (RHEL) scales really well with the growing needs of my company, as long as we have licenses.

I find customer service and technical support for Red Hat Enterprise Linux (RHEL) better than most; it's good.

Positive

Before Red Hat Enterprise Linux (RHEL), we were using SUSE Linux, starting originally with Red Hat, then switching to SUSE 10 and 11, and ultimately switching back to Red Hat 7.

My experience with deploying Red Hat Enterprise Linux (RHEL) has gotten easier over the years, especially with Ansible, as it has become more automated, replacing a lot of the tasks we used to do by command-line interface with more Ansible playbooks and workflows.

From my point of view and a technical perspective, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) is the ease to spin up the instances and the fact that many people still prefer the command-line interface, which has significantly less overhead than a Windows system.

Regarding the pricing, setup costs, and licensing of Red Hat Enterprise Linux (RHEL), I'm not really involved with the budget, however, it seems to be okay for what we currently have.

A while ago, we considered SUSE and looked at Ubuntu before we ended up choosing Red Hat Enterprise Linux (RHEL) as our solution.

I rate Red Hat Enterprise Linux (RHEL) an eight out of ten. 

To make it a ten, Red Hat Enterprise Linux (RHEL) would need to allow systems to remain operational even if licenses expire, especially on a virtualized platform, and perhaps also improve Ansible integration.

Our primary use case for Red Hat Enterprise Linux (RHEL) revolves around running and managing critical enterprise workloads. We rely on RHEL’s stability and security to support key applications, including Oracle databases, EBS (Enterprise Business Suite), and NMS (Network Management Systems).

One of the standout advantages of RHEL in our infrastructure is its integration with Ansible, which allows us to automate configurations, streamline patch management, and reduce manual intervention across multiple systems. This automation helps us maintain consistency, enhance security, and minimize downtime.

Red Hat Enterprise Linux (RHEL) has significantly enhanced our organization's efficiency, security, and automation. As the foundation for our enterprise workloads, RHEL provides a stable and scalable platform that ensures high availability and performance across critical applications. One of the biggest improvements we've seen is through Ansible, which has helped us automate configuration management, deployment, and patching processes. This has not only reduced manual workload but also minimized the risk of human errors, leading to a more resilient infrastructure.

One of the most valuable features of Red Hat Enterprise Linux (RHEL) for our organization has been its simplicity and automation capabilities. Managing enterprise workloads can be complex, but RHEL streamlines this through Ansible, allowing us to automate configurations, deployments, and patching. This has significantly reduced manual intervention and improved operational efficiency.

Security is another critical factor, and RHEL’s robust vulnerability management ensures continuous updates for Common Vulnerabilities and Exposures (CVEs), keeping our systems protected. The integration of Red Hat Insights allows us to proactively identify and mitigate risks, strengthening our overall security posture.

Additionally, the stability and scalability of RHEL have been essential for supporting key applications like Oracle databases, EBS (Enterprise Business Suite), and NMS (Network Management Systems). The long-term support and extended lifecycle maintenance ensure smooth operations, minimizing downtime and disruptions.

Overall, RHEL’s combination of automation, security, and reliability has enabled us to optimize infrastructure management, improve security, and maintain seamless operations for mission-critical applications.

One significant area for improvement is SAP certification and compatibility. Many large enterprises rely on SAP workloads, and RHEL’s limited official certifications for certain SAP solutions create challenges for businesses looking for seamless integration and performance optimization. Expanding certification coverage and tuning RHEL for SAP applications would strengthen its positioning in enterprise IT landscapes.

Another key improvement would be user-friendly patch management. While RHEL provides strong security updates, further enhancing the patching process—especially with live-patching options—could minimize disruptions and make the update workflow even more intuitive for IT teams managing large deployments.

Additionally, expanded cloud-native support would be beneficial as organizations continue shifting toward hybrid and multi-cloud environments. Strengthening native integrations with cloud service providers, optimizing containerization tools, and improving Kubernetes compatibility could boost RHEL’s efficiency in cloud deployments.

I have been using Red Hat Enterprise Linux (RHEL) for the last ten years.

One of the key contributors to its stability is the predictable release cycle and long-term support. Red Hat provides extended lifecycle maintenance, allowing organizations to run workloads without unexpected disruptions. Additionally, the continuous security updates and proactive vulnerability management reinforce system integrity, reducing potential risks and downtime.

Moreover, RHEL’s robust package management system, combined with Ansible automation, further enhances stability by ensuring consistent configurations across multiple deployments. The ability to automate patching and system updates significantly reduces errors that could impact performance.

Overall, RHEL stands out as a highly stable and dependable solution, making it an excellent choice for enterprises seeking a secure, scalable, and resilient operating system.

The knowledge base offered by Red Hat Enterprise Linux (RHEL) is excellent. You just need to search for your concern, and the answer is right there most of the time, and it's accurate. If something isn't there, support is also good. If you log a ticket, the response and the level of attention that you get on a support ticket is very good.

Positive

We are in both the cloud and on-premises with Red Hat Enterprise Linux (RHEL). On the cloud, we use Azure. On-premises, we have VMware and Nutanix.

I wasn't involved in discussions about considering other solutions before choosing Red Hat Enterprise Linux (RHEL) for my company, however, if that decision came to me, I would have chosen Red Hat since I have previous experience with Red Hat in my last organization. 

We did have SUSE before we chose Red Hat Enterprise Linux (RHEL). We still have SUSE since SAP workloads run on SUSE, as they have better collaboration between SAP and SUSE. We tried changing that to Red Hat maybe a year ago, however, the response from the SAP team was not supportive as they wanted to go with SUSE due to some licensing and support models that were not clear to me.

The transition is straightforward. The documentation is great. It's accurate. If you have a Red Hat account, you have access to knowledge articles. 

We're on the cloud and on-prem.

We don't use AWS for purchasing Red Hat Enterprise Linux (RHEL).

One of the key areas where we see ROI is through automation with Ansible, which has helped us streamline deployments, patching, and configuration management. This has significantly reduced manual effort and minimized human errors, leading to higher productivity and cost savings.

Another major factor is security and vulnerability management. RHEL provides continuous updates for Common Vulnerabilities and Exposures (CVEs), ensuring we remain protected against emerging threats. The ability to implement proactive security measures has reduced downtime and the costs associated with mitigating security incidents.

When considering setup costs, pricing, and licensing for Red Hat Enterprise Linux (RHEL), I always advise others to evaluate their organization's scale, workload requirements, and long-term support needs.

RHEL follows a subscription-based model, which ensures access to continuous security updates, patches, and support rather than a one-time licensing fee. While the upfront cost may seem higher compared to some alternatives, the value comes from its predictable pricing, enterprise-grade security, and extensive support ecosystem.

For organizations with large deployments, leveraging Red Hat Satellite and Ansible automation can help reduce administrative overhead, making the investment in RHEL more cost-effective in the long run. Additionally, Red Hat provides different pricing tiers based on usage—ranging from standard support to premium offerings, allowing businesses to tailor the subscription to their specific needs.

For startups or smaller teams, I often recommend exploring Red Hat Developer subscriptions, which provide access to RHEL for development and testing at a reduced cost. Similarly, cloud-based RHEL instances through AWS, Azure, or Google Cloud offer flexible pricing models, allowing businesses to scale efficiently without heavy upfront infrastructure investments.

Ultimately, I advise organizations to conduct a cost-benefit analysis, factoring in security, automation, and long-term stability rather than looking solely at initial setup costs. RHEL's value extends beyond pricing—it’s an investment in reliability and enterprise support."*

No

We use a lot of Red Hat Enterprise Linux (RHEL) for developing products for our customers. Since Red Hat is known as a popular option for many of our customers, it provides a standardized platform for us to deliver products on. 

Ansible has helped my company by managing disparate systems, allowing us to configure for specific use cases and providing common configurations, so it helps us wrangle all the disparate situations and configurations that we have across various different product teams in our labs.

When working with the Linux system, especially dealing with thousands of systems, Ansible is probably the most helpful tool. It has helped my company by managing the complexity of disparate systems, allowing us to configure for specific use cases and providing common configurations across various product teams in our labs.

My company is not particularly happy with the current pricing models that are available. We have been starting to diversify so that we can deploy machines quickly onto Foxconn or other platforms. We will probably use Oracle Linux instead because we don't want to deal with the licensing issues of putting Red Hat Enterprise Linux (RHEL) up and then tearing it down a week later. Our management chain is not satisfied with the current pricing model.

I have been using Red Hat Enterprise Linux (RHEL) for at least a decade.

There are always bugs in any software product, but it seems pretty stable.

The technology of Red Hat Enterprise Linux (RHEL) scales greatly, but the pricing doesn't scale as effectively.

The customer service and technical support are outside of what I deal with as a system administrator. I use the Red Hat support through the website most often to look up technical issues, which works effectively. If I were to rate that support from the website on a scale of one to ten, I would give it an eight or nine.

Positive

We transitioned to Red Hat Enterprise Linux (RHEL) from Fedora approximately a decade ago. More recently, we've decided to diversify so that lab compute loads that are internal, which are going to be kicked over repeatedly, are moving to Oracle Linux. We have also acquired several companies whose systems are set up to run on Ubuntu, so our environment is diverse.

We manage our Red Hat Enterprise Linux (RHEL) systems with our own internal Ansible playbooks for performing upgrades and patching, so it's all integrated for us.

Our upgrade and migration plans to stay current are a continual process. People in our labs prefer to maintain what they have because they want to stay at steady state indefinitely, but that isn't possible. We are continually working on eight to nine upgrades simultaneously.

I see a return on investment when using this product in general, as it helps us support our product development teams, which generates revenue.

I have not been involved in any cloud migrations because that's handled by a separate team. Regarding upgrades, transitioning from version six to seven was more complex. We are currently in the process of upgrading much of our version seven base to versions eight and nine, which is progressing more smoothly.

I haven't purchased Red Hat Enterprise Linux (RHEL) on AWS Marketplace, as that falls outside of my responsibilities and would be handled by the cloud team.

Regarding Red Hat management for security, we have dedicated security teams that assist with evaluations, and we partner with them for implementing solutions to security issues. 

Overall, I would rate Red Hat Enterprise Linux (RHEL) an eight or nine out of ten. The pricing structure is the main factor preventing it from receiving a perfect score, as improved pricing would enable more ubiquitous use.

Our use case involves modernizing applications for our clients. We take the application, extract the main functions and features, and modernize them to have those features in the cloud with a new customer experience. One way to do this is to prepare a new platform or solution in the cloud. Then we get the data from their on-premise services and move this data to the cloud. 

We mainly have customers from the public sector, telecommunications, and fintech, and these customers require many systems to modernize because most of them are 15 or 20 years old, and that's why they need to modernize for a better customer experience and journey.

It's almost a standard for us because all of the infrastructure in the cloud is based on Red Hat Enterprise Linux. We are using OpenShift as an orchestration platform. We work with several orchestration platforms, such as Kubernetes and EKS from AWS. In the case of Red Hat, we are using OpenShift. The main feature of OpenShift for us is the continuous integration, continuous delivery, and security; the granularity of security is important for us. They have a lot of features on top of Kubernetes. 

Red Hat is a good partner for us, and the service and support guides are really valuable for understanding and improving our knowledge in this area.

The main benefit of Red Hat is the huge community. They are delivering better quality by constantly updating and adding features for different products. The stability and quality of their service are very good.

I believe they need to improve in terms of compatibility between services. I know that it's difficult to follow the different versions and maintain compatibility. For example, in OpenShift, they have several internal tools that are not completely compatible with the product, and that's an area they need to work on. Supporting different versions and ensuring compatibility between these versions is necessary for us to continue putting effort into this.

We started on-prem about 15 years ago, and we have been working with Red Hat Enterprise Linux on the cloud for five years.

The quality of their services is high because they have people internally working on improving features every day.

Red Hat is a good partner. I would rate their support an eight out of ten.

Positive

Two of our clients switched to Red Hat because they have support from the organization. The management of their products, in terms of documentation and processes for installation and configuration, is well-documented. It's not like other open-source products in the market that lack the full support of an organization. This is the main reason they pay for licenses or subscriptions; there's an organization behind the products supporting them.

Upgrades or migrations are pretty straightforward and not complex, according to our experience.

We require a small team of between three and five people for upgrades or migrations. For such projects, we mainly have developers and cloud engineers. For the data itself, we also have data engineers.

Pricing is sometimes an issue for our clients because it's not a cheap solution. The different licenses have a high cost, and perhaps they could improve by offering different kinds of discounts or lowering the price to make this solution more appealing compared to other cloud providers.

Moving workloads between centers depends on the knowledge of the data and the frequency of synchronization. It depends on different factors, but normally, it is a matter of knowledge about the data structure and the different mechanisms and techniques for moving this data. It's not only a matter of tools; it's related to understanding how the data is structured and how often it changes.

We don't manage Red Hat Enterprise Linux (RHEL) for provisioning and patching because we work with the cloud directly. These services are managed by AWS.

We move workloads between on-prem and the cloud using Red Hat Enterprise Linux. For this, we are using other tools, such as Divisio, which is also supported by Red Hat. We have Apache NiFi and Kafka for messaging delivery and integration between the services.

If you have a multi-cloud strategy, Red Hat is a better fit. However, if you only use one cloud service like Amazon or Google, I'm not sure if Red Hat provides great benefits compared to the cloud provider. Our clients have had only one cloud provider.

I would rate this solution a nine out of ten.

We mainly use Red Hat Enterprise Linux for general applications. We have Red Hat Enterprise Linux for identity management. We use it for NTP services. Most of the bank services that run on Linux run on Red Hat Enterprise Linux. Our core applications include bank cards solutions.

It is a stable operating system, and that is why we use it. We have many team members who understand how to use Red Hat Enterprise Linux, so it's much easier to use this version of Linux to deploy services.

There is ease of use. A lot of resources are available online if the team wants to understand something. There is also the ability to use various automation tools to run multiple tasks.

For risk reduction and compliance, we have CIS benchmarks. There are various configuration files that we are able to update and change. Using the benchmarks available from CIS, I can have a template and automate that across multiple machines using automation features such as Ansible. When examining permissions for file systems, enabling login, and enabling file integrity, these are the items we would use for security.

The simplicity of patching Red Hat Enterprise Linux is most valuable. We just use the DNF update. We use the Red Hat satellite for our patch repositories, which is quite simple. I look at it at an infrastructure level because I'm in the infrastructure team, not in the application team.

The knowledge base is good. When we troubleshoot or have issues, we go to the Red Hat website. There are a lot of documented issues. They have a good knowledge base.

Identity management could be simpler. Red Hat Enterprise Linux has Identity Manager, but it is not as simple to use as Microsoft Windows Active Directory.

I have been working with Red Hat Enterprise Linux for a very long time, approximately 15 years.

It is stable. I would rate its stability a nine out of ten.

So far, I have not been affected by significant issues in terms of security.

Red Hat Enterprise Linux is scalable, so I would rate its scalability a nine out of ten.

We are using it across two sites. We have 6,000 people.

I have contacted tech support of Red Hat Enterprise Linux for some questions. Their tech support is quite good compared to other companies.

Positive

Before working with Red Hat Enterprise Linux, I used CentOS and Microsoft Windows. While comparing CentOS with Red Hat Enterprise Linux, I see stability as an advantage; Red Hat Enterprise Linux is quite a stable operating system.

I have done cloud deployments and upgrades.

It does not require a lot of maintenance. For managing Red Hat Enterprise Linux systems, when it comes to provisioning and patching, we use Ansible, which allows us to patch multiple machines. We normally use Red Hat Insights. Once we configure our machines to talk to Red Hat Insights via Red Hat Satellite, it can tell us the vulnerability status of various machines in the environment. Then, we can decide which machines are most vulnerable and patch accordingly. We can use automation tools such as Ansible to run various patches across the environment.

We have used Leap to do the upgrades from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. Red Hat Enterprise Linux 7 was going end of life. Upgrading from one version to another can be a bit complex. It is sometimes an issue because of multiple compatibilities. You need someone who is a bit skilled on the operating system.

We did the deployment ourselves, not through an integrator, reseller, or consultant.

We have four people involved in maintenance because we have many servers.

The cost of Red Hat Enterprise Linux is reasonable.

I would recommend it for mission-critical applications. It's a good operating system to run mission-critical applications.

I would rate Red Hat Enterprise Linux a nine out of ten because of the support, stability, and ease of use.

Our primary use case involves running custom applications on Red Hat Enterprise Linux (RHEL). We mainly deploy it on-premises, with applications and custom-made solutions running on RHEL for our customers.

The most valuable features include the classical operating system features, extensive community support, and the integration of open-source with enterprise support. Our customers often choose Red Hat because they receive support for open-source software, which is a major reason for its use.

I am not sure what needs improvement as our customers haven't shared any specific feedback. Perhaps some minor enhancements like a more user-friendly knowledge base and faster technical support could be beneficial.

I have been working with Red Hat Enterprise Linux (RHEL) for over ten years, with a recent focus on it in the last few months.

I find that Red Hat Enterprise Linux (RHEL) is highly stable, and I would rate its stability nine or ten out of ten. It is a fully enterprise-grade operating system, and stability is crucial for our customers.

Red Hat Enterprise Linux (RHEL) is very scalable, and I would rate its scalability at nine or ten. Scalability is vital for our customers as they often expand their infrastructure.

While the technical support could be faster, the Red Hat Enterprise Linux (RHEL) community service is excellent. The technical support from Red Hat could be rated six out of ten because of the slow response times.

Neutral

The initial setup was very easy and straightforward. I didn't experience any problems during the setup process, similar to other operating systems.

The deployment process depends on customer specifications. After discussing and agreeing on the specifications, we proceed with the deployment. We guide customers and provide recommendations as needed.

I do not have specific knowledge about pricing as I am not a seller. The price varies depending on the customer and the project. Therefore, I cannot provide an exact evaluation of pricing.

Overall, I would rate Red Hat Enterprise Linux (RHEL) nine out of ten. The knowledge base could be improved to be more user-friendly as it currently requires getting used to.