Red Hat Enterprise Linux (RHEL) Reviews

Our main use cases for Red Hat Enterprise Linux (RHEL) are running application servers, specifically database servers, and caching servers for our applications.

Many features benefit my company by ensuring the uptime is really great.

Red Hat Enterprise Linux (RHEL) helps us solve pain points. It is much more configurable, increases our performance, allows us more flexibility in management, and the automation for it is much greater. 

It is very stable.  

Flexibility and ease of use are great. I'm very familiar with it and I have a good team. It allows us to manage it with very little downtime. 

When we switched from Windows to Linux, we got about an instant 20% increase in performance, which was a very big deal. 

My favorite feature of Red Hat Enterprise Linux (RHEL) is the way the disk management works. I appreciate the fact that it's all text-based.

My assessment of Red Hat Enterprise Linux's (RHEL) built-in security features is that the security is fine.

All of our systems are internal, so a breach would have to go through firewalls and other protections before reaching the system. We do patch them regularly and scan them for vulnerabilities, running the ADE product on them among others.

The improvements for Red Hat Enterprise Linux (RHEL) that I suggest are mainly around increasing reporting on how patches are applied as it all revolves around Satellite. Any product that Red Hat is developing to help with patch management would be awesome, and that's my biggest pain point. I would like to see better reporting on automated jobs, and once Red Hat Insights gets looped to Satellite and on-prem, I'd like to be able to take advantage of that.

At this company, we've been using Red Hat Enterprise Linux (RHEL) for six years. I have personally been using it for 15 to 20 years.

Red Hat Enterprise Linux (RHEL) has definitely helped to mitigate downtime and lower risks. As far as I know, we've not had a service outage with Red Hat in six years. We've had system outages if all systems fail, since we produce a high availability setup, Red Hat has been very stable, and there's been no unplanned downtime.

Red Hat Enterprise Linux (RHEL) scales with the growing needs of my company very well, as we've been able to maintain our footprint with an increase in performance. This allows us to actually do more work with the same amount of resources.

I haven't had to open very many cases with customer service and technical support. The documentation is excellent, and the few cases I've had were solved within a few minutes, with one exception regarding NFS, which wasn't their fault. 

I would rate the customer service and technical support a nine out of ten.

We switched from Windows to Linux.

Deploying is very easy. We run everything via virtual machines. We create a Red Hat template, and then we use Ansible to configure it from there. So we have a generic template we deploy and actually give the machine an identity to use Ansible. I can deploy a system from start to finish in about an hour.

The biggest return on investment for me when using Red Hat Enterprise Linux (RHEL) is the ability to get an increase in performance, which allows us to not have to scale our hardware so fast.

My experience with the pricing, setup costs, and licensing is that we get a very good deal through our third-party VAR or reseller.

I don't deal much with the pricing. I do know the price of some things, such as the AP platform, which allows us to migrate off other solutions that are substantially higher.

I have considered other solutions apart from Red Hat Enterprise Linux (RHEL), specifically evaluating Oracle Linux in the beginning. Between the price considerations, as they claim to be bug-for-bug compatible, it's questionable, however, the price of Red Hat Enterprise Linux was substantially lower than Oracle's, even though they claim it's free.

We generally don't use SELinux since it causes more problems for us than it solves. 

I actually recommend Red Hat Enterprise Linux (RHEL) to everybody. It's a solid product, and I stake my reputation on it. 

If anybody wants to learn Ansible next year, this is a good platform to use. 

Our upgrade or migration plans to stay current include rolling out Red Hat 10 as soon as it's available and once we get an antivirus product that's supported on Red Hat 10. My thought is that we'll probably try to test Image Mode to see if that works for us, as it may simplify our monthly process to keep things in sync. 

On a scale of one to ten, I rate Red Hat Enterprise Linux (RHEL) a nine.

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.

We use Red Hat Enterprise Linux (RHEL) to run our web servers and application servers, and in some cases database servers. It is our primary operating system, and the majority of our servers run Unix, especially Linux.

The virtualization in Red Hat Enterprise Linux (RHEL) benefits my company as the web servers and application servers allow us to grow and be elastic about our loads and costs.

Red Hat Enterprise Linux (RHEL) helps us solve everything, from security compliance to running the core infrastructure of the company. 

My favorite feature of Red Hat Enterprise Linux (RHEL) is the virtualization. 

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades and migrations. We upgraded from version seven to nine recently, first from seven to eight, then to nine. Security requirements were a consideration when we were choosing Red Hat Enterprise Linux (RHEL) in the cloud.

The reason security was a consideration is that primarily we're dealing with the container section of Linux shops. The core of the OS cannot be touched or hacked, especially when it comes to financial transactions. When dealing with financial transactions, we need to keep certain aspects more secure, such as PCI compliance.

My team works directly with kernel patching on a monthly basis, and it's excellent; we always get the fixes for any vulnerabilities, which we have to keep up with based on the financial transactions. We need to keep up with the security patches.

Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risks. While I don't have a specific number, Red Hat Enterprise Linux (RHEL) has definitely helped in being more stable than other operating systems. When we had other operating systems, we experienced a lot of general panic with infrastructures such as older HP-UX. Red Hat Enterprise Linux (RHEL) is definitely more stable than that.

Red Hat Enterprise Linux (RHEL) can be improved by making it lighter. By making it lighter, there should be versions for specific cases, for customers or images.

I have been using Red Hat Enterprise Linux (RHEL) since 2003.

My experience with Red Hat Enterprise Linux (RHEL) in terms of stability and reliability is excellent. 

Red Hat Enterprise Linux (RHEL) scales with the growing needs of my company excellently, and that is one of the reasons we use it. We scale on a day-to-day basis using the virtualization, which allows us to add resources if we have a new client tomorrow.

Red Hat Enterprise Linux (RHEL) supports our hybrid cloud strategy as we have some legacy systems that we maintain both on-premise and elsewhere. We offer services that are not for the area where we work, which allows us to offer a better response to our clients that are further away, using Azure and different regions for them, so our Red Hat Enterprise server is closer to them instead of having it here.

Every time we have to work on a case with customer service and technical support, the response is fast. Usually, I send the information, and they have something for me within hours, sometimes even minutes.

Positive

We have considered other solutions while using Red Hat Enterprise Linux (RHEL). We have different kinds of operating systems for different clients or solutions, and while we still prefer Red Hat Enterprise Linux (RHEL), our goal is to standardize between AIX and IBM. 

We use Windows, which is challenging. We have AIX, which we run within the IBM Z environment. AIX is good, however, the hardware is not optimal, and there's a license for the hardware that is especially used for databases such as Oracle, where you need to license a whole mainframe just to run it.

From a technical point of view, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) for me is interoperability and the ability to automate a lot of the processes, from scratch to day-to-day basis.

My experience with the pricing, setup costs, and licensing of Red Hat Enterprise Linux (RHEL) has been a journey. Licensing for on-premise was different; you have your license for the hardware you're using. When doing it for the cloud, it's more of a subscription-based system. It's been variable with different pricing; we still prefer the older way.

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

I am the backend support for RHEL. We develop the stage for the application user.

Red Hat Enterprise Linux (RHEL) has benefited my company greatly because it is open source, making it very helpful to adopt.

Red Hat Enterprise Linux (RHEL) helps us solve pain points because every script and everything in RHEL is very human-friendly. We can automate processes, make changes according to our needs, edit files, add directories, and implement any modifications. Even in the RPMs, we can make changes according to our application needs, which is very helpful for us.

One of the features I appreciate most about Red Hat Enterprise Linux (RHEL) is its user-friendly interface. We have been using it continuously for this reason. As they are automating processes and introducing new methods, especially in RHEL 9, I thoroughly enjoy using the platform.

The GUI mode of Red Hat Enterprise Linux (RHEL) needs to be improved compared to the CLI mode.

I started using Red Hat Enterprise Linux (RHEL) at the beginning of my career. I have worked with RHEL versions 3, 4, 5, 6, 7, and 9. We will begin using RHEL 10 very soon.

Red Hat Enterprise Linux (RHEL) has not helped me to mitigate downtime and lower risks.

I have experience with customer service and technical support from Red Hat. When we encounter issues, we open a ticket with Red Hat, and they provide very good solutions.

When it comes to provisioning and patching Red Hat Enterprise Linux (RHEL) systems in our environment, we use Red Hat Satellite to carve out the image. We build our own image from Red Hat Satellite.

I have been involved in Red Hat Enterprise Linux (RHEL) upgrades and migrations from on-premises to the cloud. The migration process was straightforward without any difficulties. We performed both hot migration and cold migration successfully.

Reliability is key with Red Hat Enterprise Linux (RHEL), and the backend support from Red Hat is awesome. It is much easier to develop our own environment through Red Hat Enterprise Linux (RHEL) compared to other platforms such as Windows or Ubuntu. It is very human-friendly and easy to manage.

My assessment of Red Hat Enterprise Linux (RHEL)'s built-in security for simplifying risk reduction and maintaining compliance is that, compared to other vendors such as Ubuntu and Debian, Red Hat is more familiar with these aspects. We love to use RHEL.

Overall, I would rate Red Hat Enterprise Linux (RHEL) a ten.

My main use cases for Red Hat Enterprise Linux (RHEL) include application support.

Features benefit my company by allowing for cross-site administration, creating a solid baseline across our different environments and using Satellite for cross-site management.

One of the features I appreciate the most about Red Hat Enterprise Linux (RHEL) is the usability and satellite integration across multiple sites, which helps us significantly. 

Many of my current pain points are related to the automation portion with having Ansible building. I have been involved in upgrades or migrations for Red Hat Enterprise Linux (RHEL), specifically for RHEL 7.

We manage our Red Hat Enterprise Linux (RHEL) systems using Satellite and Ansible combined, which automates all of our patches, meaning the server administrator doesn't necessarily have to do anything beyond checking online to ensure that automation is performing as expected.

For the compliance part in government environments, Red Hat Enterprise Linux (RHEL) is compliant with their cyber policies, and it has extensive integration for that. There are also Ansible templates being built up.

My upgrade or migration plans to stay current involve moving from RHEL 8 to RHEL 9, if not RHEL 10, as I know that RHEL 8 reached its end of support life a few years ago, so we do have some work to do while trying to stay on top of releases and upgrades.

Red Hat Enterprise Linux (RHEL) has helped to mitigate downtime and lower risk in our environment; I've only been integrated with it for the last two years and we haven't seen any specific issues caused by Red Hat or Linux itself relating to downtime.

Red Hat Enterprise Linux (RHEL) could be improved by incorporating some of the third-party repositories, as different repos might show more options than one would get with a base builder for Red Hat, so having the choice to include those during install would be beneficial.

I have been using Red Hat Enterprise Linux (RHEL) for the last six to seven years for the company, and personally, even longer.

I haven't seen any issues with the stability and reliability of the platform; we've been building up and tearing down our OpenShift environment frequently, and it consistently comes up and down and repairs itself.

Red Hat Enterprise Linux (RHEL) scales effectively with the growing needs of my company, as we're now utilizing OpenShift to deploy applications, databases, and other resources in a containerized environment, which reflects the direction the world is heading towards in terms of containerization.

I am not involved in pricing, setup costs, or licensing, but I can say the contract deal we have with Red Hat seems pretty fair, along with the support they provide.

Positive

We did consider other solutions in our journey, particularly looking into OpenShift, however, Red Hat is probably our number one choice.

The initial setup has been straightforward. We didn't have challenges. On top of that, you have the automation. It's getting easier. They continuously build in more tools and more automated processes so we can spin up the VMs easily.

We have been involved in migrations - specifically, RHEL 7 and Linux. The lead process is relatively straightforward.

For me, the biggest return on investment when using this product is automation.

While I am not involved in pricing or licensing, my understanding is that it's a pretty fair contract deal that we have with Red Hat and the support that they provide.

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

I'm supporting a client in North America, specifically in Canada, where they are using Red Hat Enterprise Linux (RHEL) servers in their retail business. They utilize it for back office software service, specifically a software called BOSS (Back Office Software Service). We are using Red Hat Enterprise Linux (RHEL) on almost 1,200 servers, but this year, we have started migrating to Rocky from Red Hat Enterprise Linux (RHEL).

Vulnerability management and patch releases are done on time. There are no delays, and we are not leaving our environment vulnerable, which minimizes risks.

Red Hat Enterprise Linux (RHEL) has helped us mitigate downtime and lower risk. With our current patching process using Kpatch, we frequently do not reboot the servers. We only reboot once a year during application downtime to upgrade to the next kernel level, while all security patches are applied live.

Some of the best features I noticed with Red Hat Enterprise Linux (RHEL) include the LVM and the patching mechanism through the Satellite system. We do patching whenever there is a security vulnerability, and we are able to do it with the support of Red Hat Enterprise Linux (RHEL). For me these two big features, LVM and patching, are essential. 

If I can resolve an issue myself, that would be ideal, as it means I wouldn’t need to raise a case at all. The KB articles should contain all the necessary information for reference.

It would be great if they're able to reduce the price. It will be easier to convince customers to use Red Hat Enterprise Linux (RHEL) instead of open-source solutions. 

I have almost five years of experience with Red Hat Enterprise Linux (RHEL).

Scalability is fine; I don't have any challenges there. However, we are not using many of those features because our application is not ready to utilize them.

We use their knowledge base to find the solution.

I would rate the technical support with Red Hat Enterprise Linux (RHEL) a nine out of ten. 

Positive

The customer is moving to Rocky. It is not our decision; we still insist on Red Hat Enterprise Linux (RHEL) due to its security and additional features. The customer is moving away primarily for cost-cutting on licensing. 

Compared to other Linux distributions such as openSUSE, SUSE, or Rocky, I believe Red Hat Enterprise Linux (RHEL) offers better features. In Rocky, we don't have a live patching mechanism.

Deployments or migrations are quite easy for us since we have been working with Red Hat Enterprise Linux (RHEL) for the last five or six years. It feels like a piece of cake. Whether it's a minor or major version update or a migration, we don’t face any significant challenges. The process is smooth.

Initially, it took us two days to spin up a VM with all the requirements when on-prem. Now, the code is in GitLab. We have set up a code to build the servers, so after submitting a request in ServiceNow, it can be ready the next day. It is all automated.

It was on-prem, but last year, all of the servers were migrated to GCP.

There isn't much difference whether it's on-prem or on cloud, because the patching mechanism we follow through the Satellite system remains the same. From an admin's perspective, there isn't much difference between cloud and on-prem support.

As we lift and shift, our application is not cloud-ready or digital-ready, so we are still working in legacy mode. Therefore, we need to recode the entire application stack to make it compatible with cloud features.

If Red Hat Enterprise Linux (RHEL) can reduce its pricing, then it would be easier to convince others that there is not much difference between open-source solutions while still receiving several features for a licensing cost.

I would rate Red Hat Enterprise Linux (RHEL) a nine out of ten.

Our main use case for Red Hat Enterprise Linux (RHEL) at the moment is for our dev machines, as we do software engineering for automotive, and we have a lot of developers who need Linux. We had a bunch of systems and other things, and we are now rolling them all to be standardized on RHEL.

The management dashboard, RHEL satellites, Ansible, and all those integrations have been the most valuable features of Red Hat Enterprise Linux (RHEL) that really help us. 

The features of Red Hat Enterprise Linux (RHEL) allow our company to standardize our fragmented ecosystem, which consists of a lot of Windows systems and different development environments, so that we can move away from the 'it works on my machine, it doesn't work on your machine' issues.

We are deploying workstations with Red Hat Enterprise Linux (RHEL), and we also look at deploying on-prem. We already have some cloud deployments through third-party contractors, and we are trying to tie it all together into one system. We also have high-performance compute on-prem for doing GPUs, CPUs, and simulations, and we have workstations on-prem with potential cloud workstations as a migration area.

We are migrating some workloads, such as local development tasks, to Red Hat Enterprise Linux (RHEL), but we haven't really started with the servers yet. Currently, we manage our Red Hat Enterprise Linux (RHEL) systems using the cloud portal to build a custom image for our machines, but we want to move toward satellites and use that as our comprehensive management and patching tool.

Utilizing all the security features of Red Hat Enterprise Linux (RHEL) is really important for us as an enterprise with a lot of security focus in automotive and intellectual property, and we are easing into some features such as different security profiles to ensure a secure experience for our users.

We have been trialing on Red Hat Enterprise Linux (RHEL) 9.5. We are now looking at moving towards RHEL 10, which is going to be one of our migrations before we go full production launch on this, and we're looking at doing incremental upgrades as we go to have the latest stuff available.

With Red Hat Enterprise Linux (RHEL), there's a lot of fragmentation in the documentation across different versions, and ensuring that the right version is being read can be challenging. Features such as AI assistants would provide a more unified experience, which is really helpful for IT teams who may not be Linux-centric.

I have been using Red Hat Enterprise Linux (RHEL) for just a couple of weeks as we are starting to deploy it. We originally did not have any Linux systems with us and are now moving forward with that whole process.

The stability and reliability of Red Hat Enterprise Linux (RHEL) seems to be rock solid from our perspective, as we have workloads running continuously 24/7, and the only reason we shut it off is to install a full reboot update or if the workload fails due to our own issues.

Red Hat Enterprise Linux (RHEL) is definitely going to scale with our company's growing needs. Other elements of the company have been using RHEL in production, and from our perspective as a small R&D center, it provides the flexibility to manage multiple sites in California, Michigan, and keep them all synchronized, reducing the need to send IT individuals to California to fix problems.

I would rate the customer service and technical support of Red Hat Enterprise Linux (RHEL) a ten out of ten. We really felt that with our Red Hat partner, there's personal service that has helped us build better solutions for our team; it has been a truly awesome experience.

Positive

I have only been with the company for a year and a half, so I'm not aware of anything they've done with other Linux OS solutions, however, we have primarily been Windows from a developer perspective, and now we are starting to get into using Linux systems on a daily basis, focusing on workstations for now.

We purchase Red Hat Enterprise Linux (RHEL) through a roster indirectly, and that will be our deployment methodology for any AWS deployments of RHEL AMI images. My assessment of the pricing, setup costs, and licensing for Red Hat Enterprise Linux (RHEL) is that our finance team handles it, and I've been hearing good feedback; they find the licensing model much easier to understand.

For us, the biggest return on investment when using Red Hat Enterprise Linux (RHEL) has to do with standardization and the ability to manage a fleet of devices, whether on-prem, in the cloud, or servers, through unified portals using standard processes and reducing fragmentation among machines.

Before choosing Red Hat Enterprise Linux (RHEL), we looked at Ubuntu Pro and a couple of other options, however, we decided that RHEL fits better into our ecosystem, particularly in our adoption of OpenShift for DevOps, as it's best for our developers to have the same development environments from end to end.

On a scale of one to ten, I would rate Red Hat Enterprise Linux (RHEL) a nine.

A lot of our Red Hat operating systems run middle-tier applications. We are mostly a JBoss shop, so they are homegrown applications. They are Java-based. We have several types of applications. We have identity, security, Oracle database, etc.

Red Hat Enterprise Linux helps with standardization. A lot of middle-tier applications hosted in the data center or in the cloud are unified in one standard operating system, which is Red Hat Enterprise Linux. On the data center side, we only have Red Hat Enterprise Linux. We have one unified operating system.

For our containerization projects, we are looking into OpenShift. Our Ansible Automation Platform executioner uses container-based Red Hat Enterprise Linux. We use Podman. We have moved to the Red Hat Podman container. It is a lot easier. We can scale up easily and manage it. It reduces the security risk. We do not have to worry about patching. We can just image a new container that is up to date. That is great.

We had a situation where we had to create an image for Red Hat Enterprise Linux 9, and there were built-in playbooks for hardening the system. We were able to run that and create the image. It made the work much easier than it used to be in the past.

Red Hat Insights provides vulnerability alerts and targeted guidance. It has that capability. It has a lot of features built in that not only help with security but also with misconfigurations. If a system is misconfigured, it detects that. It gives you the solution for the problem it captured. It is a great tool, but we have been focusing on the security perspective. We have not been focusing on operating system configurations. I have not yet looked at the new version, but in my opinion, it would be better if Red Hat puts a lot of focus on Insights and take it to the next level where the company could use it for its OS compliance.

We have all types of different versions running in our environment except the obsolete ones. We are moving towards versions 8 and 9. We have had version 7, and it has been very stable until now. It is ending this year around June 30, so we are in the process of moving to version 8, and we have just released an image for version 9. So far, version 8 has also been very stable.

It is a Linux-based operating system. It integrates with our automation base. We have Red Hat Satellite and Red Hat Ansible. All the engineers who are a part of our infrastructure or operation on the Unix side are Red Hat Enterprise Linux certified, so it is a lot easier for us to manage and integrate with the tools that we have. It makes much more sense from the middleware perspective and management too.

The bootup time for Red Hat Enterprise Linux running on physical hardware in the data center can be improved. We have seen cloud-based Red Hat Enterprise Linux, and it is instantaneous. You wait for a few seconds, and the operating system is up and running. It is a lot faster, whereas it takes a very long time when running Red Hat Enterprise Linux on physical hardware.

We used Red Hat Insights, but we are more focused on compliance, patching of operating systems, and things like that. In the past, when we looked at Red Hat Insights, it was its own platform, and then it migrated to Satellite. Companies are struggling to be compliant from the security side. Everyone is focused on how to patch the systems, what the environment looks like, whether they are under 90-day CVE, how their environment is compliant, and where they can see it as a dashboard. I wish Red Hat Insights was focused on that. From the Red Hat perspective, I am not seeing any sessions. I do not see anyone talking about that, which is a huge deal for us. I would like Red Hat Insights to go to the next level where it is focused on patching and compliance.

I do not have any other areas of improvement. It has been stable for us. There is a lot we do in terms of automation and integration. I know Red Hat 8 now has Podman for containers. Cockpit has a UI, so that is good now. That helps with certain things.

We have been using Red Hat Enterprise Linux for close to 20 years.

We have not run into something that caused a huge problem to our environment. If something is happening, such as it is running an Oracle database and that system has kernel panic or something like that, it is usually the database or application software running on the operating system. It is not the operating system itself.

We have not run into any major infrastructure incident costing us because of the operating system. They have it integrated with all other products such as OpenShift, OpenStack, etc.

We have three data centers at different geographical locations. Two are in the state of Georgia and one is in Las Vegas. In all three data centers that we manage, the compute-based are all Red Hat-based. 

We have a Red Hat TAM, and that helps a lot in terms of the problems and things that we run into. He is the interface with Red Hat. He escalates our service tickets and things like that. That is a huge help from our perspective.

The support that we get directly from putting tickets in has always been great. Red Hat Enterprise Linux is probably the best and most stable product that Red Hat has especially in regards to getting support and getting things fixed. They are on top of that. It has been a great experience. I would rate them a ten out of ten.

Positive

We used to run Sun Solaris. We were a Sun Solaris shop in the beginning. This was 15 or 20 years ago. We moved because of the Intel-based hardware, licensing, and cost reduction. Moving away from Sun SPARC hardware to Red Hat was a lot of saving. It saved a lot for the company. We can now run Linux-based systems on Intel commodity hardware using Dell.

Its usage is growing. Our team is working with other business units within the enterprise to get them onboarded to the Red Hat-based operating system. We have multiple entities that are running CentOS and Ubuntu. We have to have a standard operating system, and that is Red Hat. Our portfolio is increasing. We are growing and migrating a lot of nonstandard ones to Red Hat.

We have an enterprise technology group that utilizes Oracle Linux. We have worked with OEM. Our team is managing that too.

We are using Red Hat Enterprise Linux on-prem. We also have a cloud environment, but other teams are using it on the cloud. The cloud provider is AWS. The database team also uses Red Hat Enterprise Linux in AWS.

We use Red Hat Satellite and Ansible for Red Hat Enterprise Linux deployment across all three data centers.

My first deployment experience was almost 30 years ago. I started with Red Hat Enterprise Linux 4 or something like that back in 1993 or 1994. There has been a tremendous change in the way you install it and utilize it now. It is night and day. It has come a long way.

We implement it on our own.

Our costs are reduced. We can allocate that OpEx and focus on some other project. We do not have to struggle and say that this is how much we are going to pay licensing just on the operating system cost. We now have a model that works for us.

We are a huge VMware shop. Our licensing cost works well with Red Hat. We license based on the data center. The way our license works is that we can run as many Red Hat VMs as we want and pay for a single license. On the VMware side, we gain a lot, and it makes much more sense.

We did not evaluate other operating systems and compared them with Red Hat Enterprise Linux. We just went from Solaris to Red Hat.

We are an agile environment. We practice agile methodology. Anything we manage and deploy has to go through a sprint phase. We do not have a fully containerized environment. In the future, once we adopt OpenShift, it is going to increase our productivity because of how we manage things through agile. It is going to help us a lot.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would say that it all comes down to the company and how a company foresees security. Anything we support and manage has to have a support base. If something gets impacted from the security side, we know that we have Red Hat support, and it is reliable. We can get the patch we want. If you install an application that needs a bug fix, you can reach out to Red Hat and open a ticket. If you want to have a stable environment, then I would highly recommend getting the support and running Red Hat.

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

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.

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.