Red Hat Enterprise Linux (RHEL) Reviews

We use it for core infrastructure services, like package mirrors, configuration management hosts, and proxy requests going to the Internet or as reverse proxies in front of our applications. Our campus management software is delivered via RHEL and applications like Wikis learning platforms.

Almost all machines are running on virtualization. Only a few bare-metal systems exist today. Currently, we are not engaged in any kind of public or hybrid cloud environment.

One of the most important features is the package manager. It provides the ability to very easily roll back transactions when something has gone wrong. It is an easy-to-use tool that helps me in situations where something unexpected has happened. I found that this was one of the solution's major advantages over other distributions.

Another point that I really like is the ecosystem around RHEL. Red Hat provides security and bug-fix Erratas for every single update out there. Thus, I have a lot of pretty sophisticated information so I can inform myself about what an update is for, what could happen when I install it, or what would happen if I don't install it. The value added by the information Red Hat provides for its distribution is pretty good.

RHEL provides features that help speed deployment. We use Ansible in our environment, which is the free version that is usable with a RHEL subscription. It is pretty easy to set up a baseline configuration for each system as well as deploying our applications and configuring them.

Ansible and RHEL integrate pretty well. You see pretty quickly that Red Hat has a huge engagement in RHEL as well as in Ansible. They work very well together. This integrated approach decreases the time that we need to set up configuration jobs. It helps us to have faster deployments as well as make configuration changes faster and more secure. It is a tool for everyday use.

We use the solutions AppStream repository at some points. Compared to earlier versions of RHEL, we like that it is now easier to use the newer versions of run times, e.g., Python. 

We use RHEL to run multiple versions of the same application or database on a specific operating system. For example, we run several versions of the MediaWiki platform on the same system. We usually have one version of a database management system per host. If we need another version, we deploy it on another host.

RHEL's feature for managing multiple versions of packages is getting better. In earlier versions, when I think about the Red Hat software collections, it was sometimes pretty hard to set them up and use them on a daily basis. With AppStreams, it got easier. What could still be improved is the lifecycle information about AppStream versions. Usually, when doing a major release, I have 10 years of support divided in different support phases, but a lot of applications from the AppStream repository have a completely different lifecycle so you need to check it separately. For example, a certain node.js version will be at the end of support in 10 months. I must make a note to update to a new version before it reaches the end of support. It would be awesome if the end of support date of the application streams would follow a stricter lifecycle with aligning end dates.

The Authselect tool needs improvement. This tool is used to connect your system to an identity provider or directory service, e.g., openLDAP. There is documentation and descriptions. While there are a few use cases and examples described, it is sometimes hard to use these tools to set up the configuration that we need for our specific environment. I would like it if there was more general information about the tool, not just describing a use case. For example, here is how to do it and how to connect to some kind of openLDAP service as well as more information about when you need to configure certificate services and mutual authentication. There is room for improvement, but it is more room for improvement in the documentation area than the RHEL system itself.

We have been using RHEL since 2016. 

The stability is awesome because we have had only a few issues in operations. Once it is set up, tested, and ready for production, it just runs. For the usual maintenance tasks, like updating the system and making configuration changes, there are almost no disruptions or issues in our environment.

The availability is great. We usually don't have big issues in our day-to-day operations.

When it comes to increasing memory, CPU count, or deploying more RHEL instances, the scalability is good. We don't have any issues. However, I would guess it would be the same with another distribution.

I would rate Red Hat's technical support for RHEL very differently. It depends on the area that you are looking for support. For example, when I have an issue with a RHEL core platform, there are a lot of good support engineers available to help with my issue. There have been phases where one could get the idea that they are short on staff with Ansible experience, but it is now getting better again. However, the average experience and response times are good. Their responses are also good. When you have a difficult case, they are able to escalate it quickly. Therefore, you get an engineer with the appropriate background to help solve your issue. I would rate the technical support as a solid eight out of 10.

Positive

I was part of a working group who decided which major enterprise distributions we would introduce into our organization. Before 2016, we only used a very small number of Linux installations and different distributions. As an outcome of this working group, we decided to use RHEL and have used it since as the only distribution in our data center. We migrated from other distributions, such as SUSE Linux Enterprise or openSUSE, to RHEL.

While all distributions share a Linux kernel, there are differences in how to manage the distribution itself. A very important part is the package management. When you have to deal with tasks like updating packages, downgrading packages, and repairing damaged package databases, you want to have one package management tool that you know very well, not three different package managers where you only know the basics. To ease the management of multiple hosts, we decided to migrate to only one distribution. We hoped that we would have an advantage in consolidation. 

The complexity of the initial setup will depend on the requirements of your organization. Generally, I find it pretty straightforward. There is good documentation for it. The installer works great. I haven't had any issues.

There are special academic offerings for academic institutes, which is pretty good. We need these offerings. In my personal opinion, the prices are okay. However, for educational purposes, they could be lower. For example, in Germany, the budget in the education sector for IT is lower compared to the huge universities in the US.

When you are only using the RHEL subscription system, it is okay. It can get complicated very quickly when you need multiple different subscriptions with a lot of SKUs. 

When someone is going to look into RHEL, I suggest starting with an individual developer subscription, which everyone can get for free. With developer subscriptions, you won't be able to contact support, but you have almost all of the important applications and features of RHEL for free. You are not allowed to build your whole production on it, but you are able to develop applications, test configurations, test the platform, and try out almost everything.

In our IT environment, we were running Solaris and Microsoft Windows. It was decided that we wanted to move away from Solaris to some Linux distributions. In the process, we looked at distributions, like RHEL, Oracle Linux, Debian, SLES, and Ubuntu. We looked at all of these points: 

• What are the management tools? 
• How does it look in the ecosystem? 
• How many packages are available and the distribution repositories? 

We created huge metrics to score all these different points. There were over 200 points to score for the different distributions. In the end, RHEL was our winner.

Red Hat’s open-source approach was an important factor when choosing this solution. For example, let's say I won't use OpenStack from Red Hat anymore. There are other OpenStack distributors out there who know the application and can help us in the migration process. It is the same with the platform. At the core, the Linux distributions are pretty similar. We believe it would be easier to move to other solutions from other vendors compared to operating systems or software from proprietary vendors.

We have plans to increase usage. Every new application that supports running on Solaris or Linux is going to be deployed on RHEL these days. I hope it will be our major operating system in the data center. So, in the foreseeable future, there would only be two operating systems: RHEL and Microsoft Windows.

I would rate this solution as nine out of 10.

Our use case is mostly for application servers. We are not really using it for any of our file servers. We have a storage department who usually just deals with NAS and things like that. However, this solution is primarily for application servers.

The biggest benefit is from a security standpoint. As the product progresses and they come up with new versions, the new security features are addressing vulnerabilities. From that perspective, it has worked well.

We use Red Hat Satellite. The integration between Satellite and RHEL works well. Satellite is mostly used to manage the repositories from a secure standpoint. We also use IBM, which is for identity management and user access, and that also works well. From an operational standpoint, it works great. We are able to manage user access with IBM, and there has not been an issue. We make role and user groups as well as host groups so different groups have access to different servers, for whichever servers are in different host groups. For example, the database team may have a user group who has access to all the database servers listed in a host group. So, the access works well.

The best feature is its dependability. We have had some situations where some RHEL servers have been up and running for five years. So, it provides reliability and dependability. It stays up.

It provides flexibility for us to come up with solutions to speed up deployment, which is great. It allows us to use it in different environments and works well with different applications. For our virtualization platform, we will just probably deploy through VMware. We are able to script and code all of the hardening procedures. If we wanted certain applications installed for deploying images, it just gives us the flexibility.

The deployment and management interfaces for non-Linux users and Linux beginners are pretty robust. It works pretty well. I know the servers themselves have a UI that is a management front-end, where you can basically do everything using the UI rather than doing anything with the command line. That is definitely good for non-Linux users and Linux beginners.

The consistency of application and user experience, regardless of the underlying infrastructure, is great. It works well. The more that they add to make it a little simpler to work with the tools and applications that they provide, the better.

The solution enables me to deploy current applications and emerging workloads across bare-metal, virtualized, hybrid cloud, and multi-cloud environments. If it was a scale of one to 10, 10 being the best, I would say nine because there is always room for improvement. It is definitely up there as far as its reliability.

In the past and with older versions, you couldn't expand the root file system without rebooting the server or restarting the operating system. That is something that they have actually corrected now, which is great. They corrected that issue somewhere around RHEL 7. 

Since 2005, I have worked at various companies who have used this solution.

My current company was using it even before I came.

Once it is up and running, it is solid and stable. It has a stable OS. I haven't had any issues with it.

Usually, if there is any particular issue and it gets to a point where we need to open a ticket, then we will open a ticket and just generate a dump file. We then upload it and wait for them to respond.

The technical support has been great and awesome. They have been able to assist, provide solutions, and root cause analysis for different issues. I would rate the technical support as nine out of 10. There is always room for improvement.

Positive

Before 2005, I worked as a Unix engineer for Solaris and Sun Microsystems. Once I left that company who was working with Solaris, that is when I started being more like an administrator for Red Hat Linux for different companies.

Most companies go with some sort of way to deploy an image. I have done standard, straight installs, installing the solution to laptops. That would be the equivalent of installing it to bare-metal.

It takes maybe 15 to 20 minutes to deploy a server. That is just with all the automation that we have added as well as having to deploy a base OS image, hardening, and adding all the software that we want. For a company-base installation, it takes about 20 minutes.

This solution is definitely one of the best versions of Linux out there to use, especially if you are looking to use Linux in an Enterprise fashion. This is mainly because it has the best support out there. It is also stable and dependable.

We use outside monitoring tools, not the ones that come with RHEL.

We are using other tools to deploy base images to our private cloud. So, we're not exactly using Red Hat tools for this use case.

They are a great company overall. It is hard to say where they could improve. They have user groups. They put out a lot of messaging and information. The solution is easy to learn and get to know their products and what they do. From a personal standpoint, I have everything that I need.

If I wanted to run multiple versions of Node.js, there are ways to do that without using AppStream. More recently, I have been working with different versions of Node.js, having it in different versions on one machine. It works well. Just the fact that I have the capability is great.

Among the other distributions of Linux out there, I would rate it as 10 out of 10. If I have to compare this solution against everything else out there, this solution is at the top of the list.

We have almost thirteen servers. There are SaaS applications installed on this server. We leverage Java and the functionality during installation. We install it on the platform and configure it there. Some are custom applications. Our database is also in the Red Hat Linux environment. 

The solution offers users easy access. It's very simple to have and use, from an admin perspective. 

The offering provides me with all I need to serve the operation in terms of usage and capabilities. 

The general user commands are good. They are helpful for starting and stopping applications and restarting and editing files. The maintenance of user-level processes is easy. 

We're not using it in a graphical environment, we're only using command line mode. There may be a lot of features, however, I don't use everything since I don't need to. 

There are millions of commands you can use, although we use only five or ten.

Likely the solution has helped our organization save on costs. I'm not sure by how much, as I don't have visibility into that aspect.

It's very easy to use across physical, virtual, and cloud infrastructure. Specifically, on the cloud side, I have noted it's quite easy. Also, on a virtual machine, you can create a cloud version of your infrastructure in a minute. 

For my work, the solution is not missing any features. We;re only using the command line and that is enough for us. 

Maybe they need to make it easier to apply patches from different resources. That said, at my level of usage, I never have to apply patches. 

I've used the solution for almost ten years. 

It's a stable product.

While I'm maintaining 30 servers, there are hundreds of servers in use. 

The scalability is good. We are able to increase capacity and functionality based on our demands. 

I'm not sure if the company has plans to increase usage in the future.

I don't directly deal with technical support. I might send a ticket to my side, and if they have to, they would be the ones to reach out to Red Hat. 

We used Oracle Linux before we moved over to Red Hat Linux. We likely switched due to costs and licensing. We also use Windows extensively. Since we used the same architecture, we didn't need to use any third-party applications.

As an admin, I was not involved in the setup process. 

If there is any maintenance needed, we get support from the Red Hat team.  If anything comes up on the operating side, our team will take care of it. 

I'm only using this solution as an admin and, therefore, have no visibility on costs. 

We did not evaluate other options before choosing this solution.

I'm an end-user of the solution. I had admin-level access to the product.

Red Hat Enterprise Linux does not enable us to achieve security standard certification.

I'd rate the solution ten out of ten. 

My primary use case is for web applications and database applications. I've come across quite a few use cases at different companies.

The most valuable feature is the package management. It helps a lot. I also like the support. 

Red Hat is a Linux-supportive and well-managed offering. It helps a lot in terms of when we're working in production, it gives us the confidence that our packages are legitimate and genuine and we always have support available. It helps a lot. Red Hat Enterprise Linux gives peace of mind compared to other unsupported Linux distributions. 

I also like Red Hat Satellite. 

I haven't used Insights yet but it seems interesting. 

The ability to patch Red Hat Enterprise Linux through Satellite is a huge contributor to mitigating all of the compliance requirements.

Red Hat Enterprise Linux has absolutely affected our security's uptime. None of the other distributions are nearly close to what you can get with Red Hat Enterprise Linux. Red Hat Enterprise Linux is something that helps a lot in ensuring that your secure application is up all the time and that you're not getting hit by vulnerabilities. It is an easier way for you to mitigate vulnerabilities when they're around.

The knowledge base is very useful. The only thing is that you need to have an account to get access. In terms of the content, the relevance, and being able to use the knowledge base to address things I've needed to deal with, it's awesome. For example, I was trying to add proxy configuration to the package manager once and if it wasn't for the knowledge base, I wouldn't have been able to do it.

I like it the way it is. 

It's getting easier for the community to use it free of charge. If you have an account, you get to use it. It would be better if the community could use it on their own for lab projects.

I have been using Red Hat Enterprise Linux since 2011. It's been 12 years. 

On the few occasions I needed to reach out to support, I was very satisfied.  

Positive

I have used Linux distributions but when it comes to the work I'm doing at my company, we always use Red Hat Enterprise Linux. 

The biggest differences between Red Hat Enterprise Linux and the other OS' are the support, Satellite, Insights, and the fact that Ansible was acquired by Red Hat so you can use all its automation and toolings. The entire ecosystem works very well together.

Red Hat has not personally enabled me to achieve security standard certifications in the projects I've worked on but I could see how it would help. 

I would rate Red Hat Enterprise Linux a ten out of ten. I really like it. 

We do a lot of patching and upgrading with Ansible and we keep the host up to date all the time.

My primary use case for it is to run Jenkins servers.

Red Hat Enterprise Linux is critical for our operations. We use it for all of our Linux servers. 

It works. It's consistent. It's well-documented. These are valuable aspects to me. 

Red Hat Enterprise Linux 9 updates the Cipher Suites and the security proceeds it. I wasn't pleasantly surprised because a bunch of our server communication didn't work. Having the Cipher Suites updated is a good thing but was not convenient.

I feel positive about the built-in security features when it comes to simplifying the risk and reduction and maintaining compliance. I'm also a Windows Server administrator so, compared to my Windows Server experience, I have very positive feelings about Red Hat Enterprise Linux security based on how easy it is to keep things patched, up-to-date, and compliant.

Some of the repositories and some of the DNS versions are very old. I just deployed something using Ruby and the DNS stable repository was sufficiently old that the Ruby project I was using didn't work. 

I would like more transparency and better options other than using something like Ruby Version Manager. I'd rather be able to get modern, up-to-date versions from the base repositories.

We have been using Red Hat Enterprise Linux for ten years. We're on a bunch of different versions. We're anywhere between version six and nine. My personal project is on nine.

We still have Windows servers.  

Red Hat Enterprise Linux is very resource-intensive, and it's hard to secure because Windows, the base use case, is all things to all people. 

I generally like Linux server products. I like the way they specialize, and I like the default security posture.

We have a hybrid environment. We do have some things in the cloud. We're using both Azure and AWS as our cloud providers.

I was involved in the process of migrating our Jenkins servers to Red Hat Enterprise Linux 9. It was not straightforward or complex because we changed a lot of things about our deployment. We tried to improve and streamline, and in the process, we broke some of our pipelines. 

It was not smooth, but that was not necessarily because of Red Hat Enterprise Linux, except for some of the security upgrades. We could not use the old RSA keys that we were using with RHEL 6 with RHEL 9. This meant that we either had to loosen our security by allowing legacy keys or tighten things down. We chose to tighten things down.

Another challenge is that we have some old Red Hat Enterprise Linux applications that are running on very old versions. We are trying to get everything off of RHEL 6 and 7 and onto RHEL 9, but there are a few applications that are stuck on RHEL 6 for various reasons.

We are getting rid of all of our Linux servers, so the biggest challenge right now is migrating our applications to RHEL 9.

When it comes to provisioning and patching, it is pretty manual. The company uses VMware, and the process is pretty manual and involves a certain number of shell scripts. I know we're trying to adopt Ansible, but we're not very far along.

I've had a very positive experience with Red Hat Enterprise Linux. My only point of comparison is Ubuntu, which I use for personal projects. 

Red Hat Enterprise Linux is a solid enterprise product with a greater emphasis on security. However, Ubuntu Server is easier to use in many ways compared to Red Hat Enterprise Linux. This may just be a matter of familiarity, but I find it easier to get current versions of Ruby with Ubuntu than with Red Hat Enterprise Linux. 

This is based on my somewhat limited use, but it's my impression nonetheless. That's what keeps it from being a ten out of ten.

We use Red Hat Enterprise Linux for off-the-shelf applications and Oracle databases. 

The tool is simple and easy to use. It has good support and doesn't have many outages due to the OS. 

The cockpit server doesn't work and is useless. I don't like the images shown in GCP. I prefer the ones in AWS. It seems like the solution is in tune with what we deploy on the private cloud. 

I have been using the solution for ten years. 

We open a case whenever we need support. Whenever I need support, I contact the technical guy assigned to us and provide him with the documentation. 

Positive

I have used different OS like Motorola, Unix Flavors, Solaris, HP-UX, AIX, DG/UX, and Sonos OS. Unix is dying, and everything is moving to Linux. Linux is open-source and easier to use. 

We build our own deployment method. 

Red Hat Enterprise Linux is expensive. We have changed the cloud provider's subscription to a pay-as-you-go model. 

We use the on-premise, cloud, and hybrid versions. We have deployed it on AWS, Microsoft Azure, and Google Cloud. Most of our infrastructure is in the Azure cloud. I work in the server infrastructure team, and other data collectors work on AWS and GCP. We haven't used the tool's features like the image builder. 

The product supports our hybrid cloud strategy. We have been migrating using tools from Microsoft Azure. Its knowledge base is good. Sometimes, finding an article is difficult. However, once I reach them, it contains good information. 

We used Azure's tools for migration to the cloud. It is straightforward. We have no problems deploying the servers. Our main strategy focused on data centers.

We use the Leapp tool to manage the upgrades. It works smoothly on our Oracle databases. Leapp is straightforward to use. 

We use Red Hat Insights quite a bit. I have not explored all the features yet. We use it to look for events our monitoring hasn't picked up. It also helps us with tips and hints for fine-tuning applications like SAP and Oracle. We go by these recommendations and follow them to put the applications in place. I have downloaded the Playbooks for remediation. 

I use system rules for SAP tuning in Oracle. I do not use the image builder since we already have a process to do the server builds. I use the web console once in a while. 

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

We primarily use it for OS purposes. 

It's very good for support compared to other operating systems. For decades, it's been providing good support and service. Even during implementation, there's a dedicated team to answer any queries. We are a very big company running critical applications and having that support is very important.

The patching tool is good. We're also introducing the possibility of automation.

The built-in security features are okay when it comes to simplifying risk reduction. It makes life easier, especially in regards to the lifecycle and what we need to install, et cetera. The features and tools help us to maintain security overall. 

It is easy to maintain compliance.

The portability of applications and containers is good. Now we are just starting with the containers and anything related to Kubernetes. 

Red Hat is always providing security on time. Any vulnerabilities are immediately dealt with to fill the gap and deal with the issue.

It's a good tool. I'm very confident with this product.

The system role features for automation security configurations, et cetera, for Ansible, we started using it. We are new in terms of automation. We'll start to use it heavily in the near future. Ansible is another great tool from Red Hat.

It enables us to maintain consistency across systems over time. My role is to maintain stability, even during upgrades and patches. So far, it's been a positive experience. We use the entire ecosystem around Red Hat.

We use Red Hat Insights. From a security perspective, we may stop using it. With Insight, if you have Red Hat Satellite, it gives you an in-depth view of everything. The only thing missing is the insights related to performance. We may not continue with it. We'll see if we'll push it and have everything on the cloud. 

In the area we are using it, we are satisfied.

Maybe in OpenShift, which is our next step, there can be more improvements with integration with Kubernetes. We're not experts there yet. 

Maybe it could have a better user experience and less coding. Reducing the effort for the end user or administrator would be ideal to make daily operation and maintenance easier. 

If they can make the integration with Ansible easier, that would be ideal.

They should offer more in terms of learning materials to make learning easier. 

They need to make things more affordable or accessible. 

The solution is stable. We barely have any issues with a server setup. So far, it's manageable. The biggest challenge is the criticality of releasing patches. When we have any critical alerts we action them. We tend to try to wait for the release of a stable version. 

How many people use the solution depends on the application. We likely have thousands of users. We do have some products that maybe only have a few or a few hundred. 

We've had no challenges with scaling. It can support any type of load within the data center. 

Support is excellent. 

Positive

We did use a different OS. I have used Unix in the past. I started with Unix 30 years ago. I've also used SUSE. Red Hat offered more service and support. 

I was involved in the deployment. Our team managed the process. It's pretty straightforward. We handle implementation, tuning, and patching. 

How long it takes to implement the product depends. We're trying to mitigate the time by automating with Ansible. We want to handle one VM or server in five or fewer minutes, however, it can take days. At this point, we can provision servers in a few minutes. It's becoming faster. 

We have a team of ten to run the infrastructure on the OS level. 

I'm not an expert on ROI. We are paying to use the solution, however, the utilization we get and the support both offer good value. 

The pricing model isn't something I deal with directly. The pricing is fair, especially compared to virtualization like VMware. We do use VMware and are thinking about moving sandboxes and testing over to Red Hat. This may end up being a big cost savings with our CAPEX and OPEX. 

From the price level, the cost is almost the same for us, if we look at Red Hat versus SUSE, however, we get a higher level of support with Red Hat. 

Red Hat was always our first choice. 

We're a Red Hat customer. 

I'd rate the solution nine out of ten. 

I work in the energy sector, so we use Red Hat Enterprise Linux for a variety of purposes. These include high-performance computing, running applications like SAP, geospatial applications, and Oracle. We rely on Red Hat Enterprise Linux for a wide range of applications, including those that require running Oracle databases.

It is important to our organization to have a solution that avoids cloud vendor lock-in. We just don't want to be locked into just one side or the other. We want to have the flexibility and availability to explore other options.

One of the main reasons we chose Red Hat Enterprise Linux was its reliability and stability. Compared to the Microsoft Windows environment, the Linux environment provided much greater stability. Therefore, we decided to use Red Hat Enterprise Linux for all our critical applications at that time, as they required a Linux-only environment.

We use Red Hat Image Builder as well. The golden images created by Image Builder are okay. In our organization, we prefer to create our own images because we need to incorporate our own security measures and harden the images accordingly.

Red Hat Enterprise Linux could do better in live patching. In this day and age, vulnerabilities are constantly emerging, I feel that Red Hat Enterprise Linux has fallen backward in terms of live patching, particularly live kernel patching. There are other products available that can perform this function, and they often follow their direction. 

Currently, my company has a live patch solution where we can patch the kernel without rebooting. This is essential because certain applications cannot tolerate downtime for reboots. However, there is a security concern when the patching process is delayed, as it exposes the system to high vulnerabilities and risks. So, when critical applications go down due to rebooting, it has a significant impact on both the financial and operational aspects. It requires a lot of money and manpower to schedule and execute the reboots, and during that time, the application downtime results in losing money. I believe this is an area that Red Hat Enterprise Linux should focus on to address this challenge.

I have been using the Red Hat Enterprise Linux operating system for around 20 years. We transferred our existing subscriptions to the cloud version. We are actually exploring hybrid solutions and availability options. As we transition to Azure, we are bringing our own subscription.

The scalability is good. We are able to scale efficiently. In our high-performance computing department, they handle a lot of scaling, and it's going well. Red Hat Enterprise Linux scales well.

I'm not particularly fond of the support. For example, when we have a server that's down, we raise a ticket indicating the severity of the issue. Then we receive another email suggesting things we can try to resolve the problem. I miss the days when we could directly speak to someone because sometimes, depending on the maintenance contracts and SLAs, it can take a lot of time without actually making any progress. Whereas speaking with a support representative could significantly reduce the downtime. So, I'm not really crazy about it.

The knowledge base is good. I would rate it a nine out of ten. 

Neutral

One of Red Hat Enterprise Linux's pros is that it has been around the longest. When working in a large corporate environment, reliability is crucial. In case something breaks, you want to have the assurance that there is a reliable support system to address the issues. Red Hat Enterprise Linux provides that level of support. 

However, it's important to note that even with a solid distribution like in Red Hat Enterprise Linux, the effectiveness may vary depending on the specific customer or scenario. It's about assessing how well the distribution handles issues when the next customer raises a complaint. So, we need to carefully consider the pros and cons based on our requirements. For certain workloads and development tasks, we might consider freestyle options that don't require paid subscriptions. In my company, we have a development program that greatly supports our decision to go with Red Hat Enterprise Linux.

Personally, I find the deployment process straightforward, but I've been doing it for quite some time. I can't speak for someone who is new to it. However, from my experience, it's relatively straightforward. I've been in this role for a while, so I'm familiar with the process.

Currently, we use Azure AVS, which allows us to migrate existing physical machines to the cloud until we can fully modernize them. It's much easier than it was a couple of years ago, but there is still some work to be done. Overall, it's manageable for us to move workloads between the cloud and on-premises or data center environment using Red Hat Enterprise Linux.

We have streamlined our deployment process within our guidelines. I can build a server in just three minutes. The time required depends on the type of server we need. If it's a more specialized server, it may take longer. However, it's nothing like the old days when it used to take several days. Especially in the cloud environment, it's quite fast. On-premises is a different story because we need to consider hardware availability, which can take longer. But once we have the hardware, the deployment itself typically takes less than an hour, especially when we leverage tools like Satellite for automation.

We have indeed realized a return on our investment. If we hadn't, we wouldn't still be using Red Hat Enterprise Linux. However, we are always striving to improve our return on investment. That's why we continually conduct due diligence and explore other operating systems to ensure that we're not blindly sticking with a particular company. We want to find the best solution that can potentially save us more money while delivering an equal or better return on investment.

Red Hat Enterprise Linux is starting to realize some other companies are gaining some footing in the industry. Red Hat's pricing still needs to get a little bit better. When you look at what you pay for a subscription compared to what you can pay with some of these other companies that do offer a lot of technical backing behind them, it starts turning heads.

Red Hat should focus on making enhancements and providing better support in that arena.

Before choosing Red Hat Enterprise Linux, we did evaluate other Linux-based solutions. When we initially chose Red Hat Enterprise Linux, we had options like Solaris and SGI. However, even recently, we have continued to evaluate other distributions because the Linux landscape is constantly evolving. There are new solutions emerging, so we have to perform our due diligence and assess what they can offer.

For customers looking for alternatives to Red Hat Enterprise Linux, my advice would be to choose something that aligns with your requirements and that you are happy with. Don't just pick something because it's cheap. You gotta look at the long term. Also, know what is needed for your project. For example, if you have issues, can you get those issues resolved in a timely manner? If you run into an issue, you're stuck, and they can't help you out, this means your project will be delayed. You will need to weigh that out.