Red Hat Enterprise Linux (RHEL) Reviews

I work in the financial industry in Brazil and my first job was to use Linux.

We deploy Red Hat Enterprise Linux on-prem and in the cloud. Our cloud provider is AWS. 

We use Red Hat Enterprise Linux for web applications, including the JBoss data bridge. We also have some applications for prevention and risk. Red Hat Enterprise Linux is used for most of our applications in Brazil, so it is used for almost everything.

We run our workloads and applications on AWS.

There are many Linux-based operating systems. We wanted an operating system that was mature and reliable, and Red Hat Enterprise Linux was the best choice for us.

Red Hat Enterprise Linux is a highly resilient operating system. It has a strong XFS file system, kernel, and package build.

Migrating workloads between the cloud and our data center is easy. There are no problems.

The knowledge base offered by Red Hat Enterprise Linux helps a lot. It is very useful and has helped me to resolve the issue by looking at the documentation.

The integrity of our operational systems is very stable. Red Hat Enterprise Linux has a good file system type and good kernels. It does not crash for any reason. This makes it a very stable platform for me. It is the best solution for our needs.

There was a reduction in the amount of detail provided in backlog messages between Red Hat Enterprise Linux versions six and seven, compared to versions eight and nine. This makes it more difficult to troubleshoot errors in versions eight and nine, as users must dig deeper into the operating system to find the source of the problem. Versions six and seven provided more detailed error messages, which made it easier to identify and fix problems. Deploying applications using Red Hat Enterprise Linux versions six and seven was seamless. However, there is a chance that something could be broken when deploying with versions eight and nine, and we may not know it.

I have been using Red Hat Enterprise Linux since versions four and five.

Red Hat Enterprise Linux is extremely stable.

One of the reasons we adopted the Red Hat Enterprise Linux ecosystem is because of its ability to scale.

I have not had a good experience with Red Hat engineers. When we have an issue, it is very difficult to have it resolved in the first call. They always have to escalate the issue and involve multiple people. At a minimum, we have to escalate an issue three or four times before it is resolved. The support team in Brazil has helped me a lot because they work with me to resolve the problem, but if I have to open a ticket and follow the steps I never get proper service.

I give the technical support of Red Hat a zero out of ten.

Negative

The initial deployment is easy. I can deploy Red Hat Enterprise Linux myself using a base image within a few minutes both on-prem and in the cloud.

The implementation is completed in-house.

We purchased our license from Red Hat.

I give Red Hat Enterprise Linux an eight out of ten.

Cloud vendor lock-in is inevitable when we adopt the cloud. This is because once we adopt a cloud service, such as DynamoDB or AWS, we become dependent on that provider for support and maintenance. It is very difficult to work with multiple clouds 100 percent of the time, as this can lead to problems with failover and other issues in multiple cloud environments because the risk is high.

The Red Hat Enterprise Linux ecosystem is more attractive because we are not just buying an operating system. We are buying an ecosystem that helps, supports, and secures our platform. I believe this is the better option.

Applying patches in the new versions of Red Hat Enterprise Linux is more time-consuming than in Oracle Linux because Oracle Linux does not require legacy environments to be patched or changed through applications.

For someone looking for an open source cloud-based Linux OS instead of Red Hat Enterprise Linux, I recommend AWS Linux. It is a very stable version of Linux and does not require a subscription.

Our company uses the solution to provide DBA services and manage Linux databases for clients. 

The solution works well both on-premises and in the cloud. We deploy based on client preferences that include on-premises, hybrid cloud, and fully public or private cloud. 

Depending on use cases, we use different cloud providers such as AWS, Oracle, or Azure and they all have their own limitations. The solution is flexible and has great scripting so it can accommodate any conditions. 

For one client, we have version 7 installed and managed on a variety of physical servers for different environments including production. For another client, we have VMs. For other use cases, we have a setup of active sites in on-premises with standbys in the Azure cloud. 

The solution has enabled us to centralize development because it provides true automation. It ensures that systems are stable. There is no room for doubt with our clients because the protection is sound. 

Productivity and efficiency are key advantages because the solution automates regular tasks and processes. All of this benefits our company. 

The solution integrates with all types of software and is much easier to manage than a Windows system. 

Management is portable and easily automated so deploying or installing packages and running updates is seamless. You can automate as much as possible from the deployment and maintenance points of view, both on-premises and in the cloud. 

The operating system is very stable and robust with a very good kernel. You don't run into issues related to the core of the operating system.

Updates are constant and delivered pretty regularly. The solution covers most vulnerabilities so we feel pretty confident using it on different machines. We can tell within 30 days that patches or updates are good. 

The solution could provide more APIs and GUI interfaces. The current options are kind of low-level and not as visual as Windows. 

I have been using the solution for 15 years. 

The solution is very stable so I rate stability a nine out of ten. 

The solution is scalable so I rate scalability an eight out of ten. 

I used technical support once and they responded very quickly with useful information. 

I rate support an eight out of ten. 

Positive

I previously used AX, HP-UX, and Solaris at a prior job. My current employer has always used the solution. 

The setup is straightforward. 

For one client's cloud setup, we created virtual machines and provisioned the operating system on the solution. The cloud solution provides images for the operating system so is pretty easy to install. Just click, click, click and that is it. 

For other cases, we had to install from scratch at boot but had well-documented instructions so we didn't have any issues. 

These use cases were not too complex so the focus was more on installing patches and packages that ensure compatibility with the solution. We find prerequisites for implementation in order for it to work. We focus on a strategy that makes sure we have the correct kernel parameters, the right center for settings, and the utilities needed for managing the operating system in conjunction with the database. For example, a lot of C++ compilers need to be installed. Everything that is part of the pre-install packages can be done by a DPA as well. 

We deploy the solution in-house for customers and it takes a few hours.

Ongoing maintenance includes applying versions on occasion to make sure processes aren't hanging, over consuming, or missing resources. 

Each client has a set of servers and databases, so maintenance might require two to six system administrators. It all depends on use cases including the number of systems, how critical systems are, and whether you need downtime. 

It is important to make sure your patches are up to date. Any part of regular maintenance should not be skipped. 

I recommend the solution because it is stable and easy to manage. I rate the solution an eight out of ten. 

We have a very large system with ten application teams. We've got four DevOps squads that support those teams. We use this solution to containerize about 85% of our applications and software. OpenShift 4 maintains our applications and our databases, keeping our system up to date and it integrates with our CI/CD pipelines.

We also use OCS for security compliance.

RHEL runs as the backbone for our applications. We are able to meet our deadlines of becoming the system of record and creating an operational maintenance system, on time and under budget. Our system processes 4.7 million customers' flood insurance policies yearly and processes their claims. It's the backbone for all of our applications and what they do.

RHEL's built-in security features have helped us reduce risk and maintenance compliance. We've been switching over even some of our build pipelines to use OpenShift. We are able to run a GitOps model to be able to track and store changes and then press the button to be able to sync it with OpenShift and this has been great.

The containerization capability has been most valuable. Having our applications and our databases containerized has allowed us to be able to migrate from our on-prem site to the cloud in a much faster timeframe. We don't have to change the applications or databases and there's a lot less rearchitecting. That has been a game-changer for us.

The OCS is built to help monitor and scan OpenShift 4 containers and Core OS. That integration has been seamless for us.

This solution could be improved if it was easier to set up and run in cloud environments. It can also be costly to manage a large OpenShift environment.

We have been using RHEL since 2016. 

This is a stable solution.

We're about to build out and use the elastic capabilities to spin up OpenShift clusters as needed on demand so we're about to find out if it is scalable.

It's been great. We've been having weekly meetings with them as we migrated to Google. They've been a great partner in providing support as needed in helping troubleshoot issues.

I would rate their support a nine out of ten.

Positive

The initial deployment and setup of OpenShift were straightforward. We ran into some issues that we were able to work through. The Red Hat team did provide a lot of support to get us there.

We have an O&M contract that helped do the setup, and then we did consult with Red Hat on it. Guidehouse is the contractor that provides support for development in O&M. They've been a great team and partner to us. 

OpenShift being containerized has meant that we've been able to move from the on-prem to the cloud in a much faster time period.

I don't have any issues with the licensing or pricing. In general, OpenShift is a little more expensive. It's a bit expensive to have the number of containers we need and for disaster recovery but it's been worth the money because it's helped us get to the cloud faster.

It is easy to troubleshoot with RHEL. I would rate this solution an eight out of ten. If you are in the government space and you're looking to modernize your systems but you're not quite sure about the cloud, using OpenShift to containerize is a good first step. It will give you that cloud-agnostic capability so that you're more readily able to move to the cloud when you're ready.

I would rate this solution an eight out of ten. 

The main use case is general system administration, which includes configuring networking, configuring storage volumes, managing users, and running backup applications.

Application performance is one of its main benefits. The applications that run on RHEL are very stable. 

I've not done much work with containers, but with general applications, as compared to other solutions that I've used, RHEL has the best portability. I have not had any issues or application failures while migrating. I've moved virtual machines and systems from one platform to another, and I've never been scared of RHEL. I never had to deal with application failures while moving them from one place to there. That's why I'm pretty confident with RHEL when it comes to working with it.

I like its integrations. I would put it higher than any other Linux version when it comes to availability. Its integrations with different applications and solutions are the best. We work with a lot of clients that use RHEL, and we could easily and quickly integrate any cloud solution, virtualization solution, storage solution, or software with the RHEL system. It is better than the other solutions we have worked with.

I like the way the updates are done and the way packages can be installed through the Red Hat Package Manager. I like it because of how fast and straightforward it is.

Its user interface could be better for people who want to use the GUI. They can provide a better user interface with more features. Storage works perfectly fine. Of course, continuous improvements should be made all the time, but it isn't at all lacking when it comes to storage and other features.

I've been using RHEL for four years, but in the last 12 months, I've used it more.

It is the most stable one. It is very stable. 

It has the ability to scale. I know that it can scale, but because of my limited experience with scaling, I don't know how good scaling is. I have only done the basic scaling, but I would assume that it can scale way more than what I have done.

Most of my usage of it is on a private cloud. I've used it in a hybrid cloud environment, but I've not done a lot of work with the hybrid cloud because most of the clients we work with have private clouds. The little bit of experience I have had with the hybrid cloud was related to basic application installation and scaling. For the scaling part, I was able to have the applications first in the private cloud and then migrate or move it to a hybrid cloud. I was able to integrate them, and I was able to change the environment, as well as have them work in a cluster. The scaling part was seamless. It was pretty easy. It was easier than I thought.

The private cloud is deployed at three locations. The public cloud is deployed across two regions. There are a lot of users of this solution. There are different systems for different applications and different services. I can't put a number on the total number of users. Some systems have 50 and some systems have close to 70. There are systems with just 10 or 5 users.

They can be faster. Because I work in support, I classify support in terms of how well you can resolve an issue and how fast you can resolve an issue. They don't reply fast enough. In a lot of instances, they don't get back to you immediately, and you have to wait for a while after creating a support ticket. They can be faster at that, but when it comes to resolving your issue, they are good. Overall, I would rate their support a seven out of ten.

Neutral

Prior to using RHEL, I was using Windows. I've also done a lot of work with Ubuntu, SUSE, and other Linux solutions, but Red Hat is the best one. I prefer it over other solutions because I'm used to it, and I find it better than other solutions. I'm used to the commands, and it is easy for me to navigate my way through it. If I have to choose between Windows and Linux, I would always go with Linux and choose RHEL because of its stability and agility.

I also use CentOS for my personal things or running some tests. For example, if I want to run a test with a client, it doesn't make sense to run a test in the client's production environment. I have a test environment with CentOS, and I run the test on CentOS before going to RHEL. I'm pretty comfortable using CentOS. CentOS is like my own testing environment.

The reason I switched over to RHEL was that over here, almost everybody or every client who uses Linux has RHEL. So, I had to understand how RHEL works. I realized that most people use it because of its stability. People find this system and its architecture good. A lot of clients talked about how they preferred the architecture of RHEL. Some clients find the commands to be easily readable, and some clients find it easy to integrate with others. A lot of clients find patching and package management pretty easy.

In terms of the deployment model, we have a private cloud. We have VMware for virtualization and Azure Stack for the private cloud. There are also public clouds, such as GCP, AWS, and Azure, and then there is the physical hardware. Some of our deployments are on physical hardware. So, we deploy RHEL on physical servers, and then, there's also the hybrid model when some clients want to integrate the private cloud and the public cloud together. They want the public cloud to be like a backup environment, or they want the private cloud to be a backup environment.

I was mostly involved in the deployment of the hardware and the private cloud.  I was also a part of the team that set up the hybrid environment, but I didn't do a lot of work on the public cloud side. The only complex part of the deployment was the hybrid configuration, where we were trying to interconnect the private cloud and the public cloud. The deployment on the public cloud was more straightforward than the deployment on the private cloud because, on a public cloud, the image is already there, whereas, on a private cloud, you have to set the image up yourself.

Each deployment model took approximately one week to deploy, but the hybrid model, requiring interconnecting the private and public clouds, took more than a week because there were a lot of dependencies.

In terms of maintenance, it does require maintenance. That's the main reason why people pay for support. 

We have definitely seen an ROI. There are around 15% savings.

It is pretty expensive, but it is worth it. Generally, in an enterprise environment, there is no cheap solution. This is coming from someone who is working with a company that provides a lot of solutions a bit cheaper than the industry standard. In the enterprise environment, I believe no solution is inexpensive, but RHEL is still pretty expensive.

Additional costs that I am aware of are usually for support and setup. A lot of banks use RHEL. I've seen the cost of the support and setup. Some of them complain about it, but they also talk about how well it works.

I have not compared the overall costs of open-source competitors to the overall costs of RHEL when it comes to supporting business operations over time. The only other distribution for which I have seen the pricing is AIX, which was a bit more expensive than RHEL.

I would always advise doing a proof of concept where the client gives out his requirements and you run a proof of concept based on those requirements to make them confident of purchasing the solution. It is always better if a proof of concept is done. This way, everybody knows what they're getting into.

Its built-in security features are definitely helpful, but at the end of the day, you have to go further than using the built-in ones. You have to do a few other things yourself. The built-in features are helpful for compliance, but we, and most enterprise organizations, always want to go further than using built-in features because some built-in features could be more open to risks. We use the best built-in features, but we always want to go further and integrate other features into the RHEL system.

I have used Red Hat Insights only once, and I have not worked much with it, but my colleagues handling monitoring used it. It was helpful for the unpatched system. They checked Red Hat Insights and saw the systems that need patching. We got an email saying that it is a security requirement and that we need to patch them because it may affect the security of the systems. Coincidentally, after doing the patching, we read blogs about security hacks out there for some of the older systems that were not patched early enough.

Red Hat Insights provide us with vulnerability alerts, but I am not sure about targeted guidance. Vulnerability alerts have impacted the uptime, which is something that we take very seriously. Uptime was one of the major reasons we wanted to work with Insights because we didn't want any attacks that would cause downtime.

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

Our company uses one of the solution's varieties, mostly CentOS. We are restructuring and moving to the licensed version of RHEL and its derivatives. 

We use both RHEL 7 and 8 mostly in the cloud but also have a small data center where the solution is used on bare metal. Our team does a lot of AIML work where we set up instances to run simulations. 

We are moving a bit into Redshift because we do not have many staff members with containerization or Kubernetes experience. 

We run most things on the solution and its impact has been huge. We do have a few items on Ubuntu but question its use. Conceptually, Ubuntu is for amateurs and RHEL and CentOS are for professional organizations with hardened security. 

The YUM repository is valuable. We are in an interesting situation because we cannot have access to direct YUM or browser repositories so we have to copy to a Nexus server and pull from there. From what we have seen, pretty much everything is available right there. 

The solution's use of Kubernetes as an internal or core process on the system is brilliant. You eventually get to Kubernetes whether via Redshift or other tools and do not have to worry about your hardware because you deploy and push to the infrastructure without worry. 

The Cockpit makes it very easy to maintain systems because you do not have the overhead of running gooey but still have the interface. I am a Linux person and had issues with Windows because they required gooey on servers when it was not necessarily needed. 

The solution is moving away from CentOS and there are growing pains from the customer's perspective. It was purchased by IBM and they are for profit which everyone understands. There is a huge shake up right now because customers who run CentOS do not know what to do with all their systems. One of the reasons CentOS is used for government offices is its security feature that does not change because it occurs after route. The solution placed CentOS in the middle so government customers do not trust it. The way the rollout occurred caused a lot of mistrust with Red Hat. 

The SELinux is great but the Amazon security features cause issues. For example, we run RHEL and CentOS on AWS but they control the cloud and do not give us access to security features. We have to go through multiple layers to deploy an instance. Something that could be controlled with a firewall or blocking ports is now controlled by security groups inside AWS that we cannot access. 

I am newer to the solution but our company has been using it for a long time. 

I previously worked with an Intel customer who used a lot of CentOS, so I am aware in that sense. I am very familiar with the YAM and DNF. I have even played a bit with Rocky which is not specific to the solution. 

My work in systems and software supports one of our teams. 

Technical support staff are personable and quick to get to problems. Support is better than other vendors and I rate it a ten out of ten. 

Positive

I used to work for a government organization that was heavily into AWS. One of the reasons they embraced open source was because Oracle was too expensive. They put everything into AWS rather than open source, so they will soon be in the exact same position where everything is proprietary. 

The solution is easy to set up but sometimes there are issues with custom software deployments. For example, we want to use Ansible in RHEL 8 but the software is only supported in RHEL 7. We question whether we should install an old version of Python to get things to run. 

The solution is pretty easy to troubleshoot. 

Our organization is huge but I handle the setup for instances in our small data center.

I do not deal with money, but I see an ROI in terms of the engineers' skills because they can reapply them to multiple RHELs and incidents. 

The solution is moving away from its open source roots and licensing is a little bit of an issue. 

We use Ubuntu, but not much. 

Primarily, we are dedicated to RHEL and CentOS to the point that we do not see Windows as a viable server option. Microsoft's cloud is getting traction but it only makes sense if you have a solution meant for Windows. 

We also use Redshift and Cockpit. There is consistency across products so they are backward compatible with familiar operations. For example, you could use RHEL 8, YUM, or DNF because the syntaxes are identical.  

The solution is very into Ansible and we are trying to drive everything to it.

Look at the security features of the solution and compare them with other options. Open source is great, but at the end of the day, you need someone supporting the product. Another option is to just listen to groups that write on the internet, but you have to decide if you trust that along with their adversaries. 

Government offices have to worry about adversaries from other countries because the code they use is unclear. The idea of open source is to be able to evaluate the code but it is not clear if anyone actually reviews it. 

I rate the solution a ten out of ten. 

We have warehouse management systems (WMSs) where we run Oracle as our database. The app tier is basically Java. We are using a vendor-supplied Java, and the application itself is managed by the vendor. There are just one-offs here and there, such as utility boxes, but the majority is Oracle and the application that connects to Oracle.

On larger systems, like HANA, we have it deployed physically. On everything else, we have deployed it in a VMware environment. It is all on-premises. While there is some cloud, that is being done by contractors. 

We are on versions 6 through 8. As soon as version 9 gets released to GA, I am going to start working on getting that image ready. Currently, about half our images are on version 8, two-fifths are on version 6, and then version 7 is squeezed in-between.

The solution provides features that help me tweak or configure the operating system for optimal use, such as Insights Client, which I have used quite a bit to help me.

Our users are removed from the environment. They don't really know that they are running on RHEL. There have been very few complaints about speeds, application, or stability on RHEL platforms. Whereas, on Windows platforms, there are a lot of complaints.

Satellite 6.10 and RHEL integrate with each other perfectly. This integrated approach enables me to be a single person managing my images since it does a lot of the manual labor that I used to do, such as building patches, doing system maintenance, and keeping systems consistent. It does all that stuff for me. So, it has offloaded those responsibilities, giving me more work-life balance.

It is a bit on the pricier side. However, due to the stability and support that they provide to my management and me, we really don't see a reason to choose another way to go. Red Hat offers excellent support in a sphere where it is difficult to find good support.

I have been using RHEL since 2013.

It is a good operating system. It is very stable. It does not take a lot of maintenance. You set it up well and it runs. To give some perspective, we also have Windows admins. That team is about six people and growing. They manage twice as many servers as I manage, keeping them busy all the time. Whereas, I pretty much have a life; the work-life balance is very good.

RHEL is very stable. You build an image and deploy it, then it runs.

As far as the operating system contributing to reliability, it is very stable and has low maintenance. It keeps running.

We found that two of our outages in the past eight years were related to the operating system. All our other outages were related to the application and the use of the application.

I don't find the solution’s tracing and monitoring tools impact performance at all.

We can scale out. When we need more machines, we just build more machines. That is not a problem. We don't do the scale ups or any of the other scaling that is out there. That is partially because of the way our applications work. You need to scale according to the application. If the application requires new nodes, we just spin up another node and it is no problem. I could run 10,000 images, and it is not a problem.

Because we buy companies, we will probably continue to increase the usage of RHEL. I don't think that will be a problem because it is so stable. We are running about 200 images right now and about 60% of those are in production. I can't see it shrinking, but I can see it growing.

I like the fact that they really dig into things and then provide answers. As the single Linux guy, I kind of need that second admin next to me sometimes to say, "Hey, what about this?" and I am able to do that through the portal. I get my questions answered and trouble tickets resolved.

The technical support is superior to many vendors with whom we interact. They pay attention. Rarely will I run into a support person who doesn't seem to know what they are doing, then it doesn't take very long to get the issue escalated to somebody else. Out of a hundred cases, I have probably escalated three times. I would rate the support as 10 out of 10.

Positive

I came from a Unix background. I was on HP-UX on OSS and AIX. So, the transition to Linux was very simple. I am a command line person, so I wasn't scared. I just moved into it and found it to be very attractive. In fact, I don't run GUIs on any of my Linux boxes.

The biggest benefit for me, coming out of the Unix arena, was that it matched Unix very closely. So, I am able to draw on my Unix experience and use that in the RHEL environment. There is almost a non-existent learning curve in my situation.

The initial setup of RHEL is about 10 times easier than Windows. It is literally just click, click, bang. It just installs. If you have a problem with the install, you just reinstall it. It takes very little time to install, about 10 minutes. As a base image, it is very easy to set up. Then, you have post tweaks that you need to do, and I have scripts for that. Since I can script it all, I just run another command, then boom and it is all done.

For my implementation strategy, I build the gold image, which is basically just going through the CD and making my selections for a base image. Then, I freeze that image, which is on VMware, and run my scripts. My scripts basically set up logs for auditing. Whether we are going to ship logs or keep logs locally, it sets up the basic users. For instance, it will set up my account with pseudo access so I can do the remainder of the work using my account with pseudo access. It sets up tracing, the host name, IP addresses, and ESXi host files. It sets up the basic fundamentals of an operating system and gets it ready for deploying the application. 

There are also different kinds of file systems that need to be deployed and additional users that need to be added. Those are all manual processes.

We have one admin who manages all the images. That is the return on investment. The company hasn't had to hire a second admin (FTE) to keep things running.

We have moved to the Simple Content Access (SCA) model. It is much easier to do renewals and see how I am using my licenses. I used to have to do it all by hand. It would take me a good couple of hours every few months to make sure that we were up to snuff on everything. However, with the new model that they have, this is very easy. I just go to cloud.redhat.com to look and see how I am utilizing my licenses. If I am running out of bounds, I can find out why. If it is simply that we have images that need to be removed, we remove those images. If we need to buy more licenses, then we can start the process of purchasing more licenses.

I think it is worth the price. I wish the pricing was a little bit more friendly, so when I go to my boss, he tells me, "That's too much money." I can say, "It's not too much money."

Especially if you are a newbie, buy the support and use the support. Get a couple of images going and really play around with them: crash them, burn them, and figure out how support functions when you have a really gnarly situation. Otherwise, it is just inserting the CD and booting the machine. It is very easy to set up and run.

I have looked at SUSE or Ubuntu. They are so radically different in their total management, e.g., everything from getting packages to configuration and in how that is all done. Therefore, it would be a learning curve to go to another solution. So, there is benefit in staying with RHEL. 

I do not have a lot of experience with Ubuntu or SUSE. Those would be the bigger contenders. The thing that I keep coming back to though as I'm talking to vendors and VARs is that though SUSE is a contender out there in the SAP landscape, RHEL has the stability. SUSE appears to function more like a desktop operating system ported to a server environment, whereas RHEL is built from the server hub. The management tools show that. It is a mature management infrastructure.

There are some things that are nice about SUSE. People talk about their app configuration wizards, but if you're coming from a Unix background overall, RHEL feels like a real operating system.

My interaction with Ubuntu has been as a desktop. It is very GUI-oriented. In my estimation, it is more like a toy. It is deployed in server environments, but it is more because admins are familiar with the desktop version of it. They just port that over as opposed to having grown up on Unix and moved into Ubuntu.

A Unix admin will prefer to go into something like Red Hat, Rocky Linux, AlmaLinux, or even Oracle Enterprise Linux because they will simply feel much more like a data center operating system than some of these other solutions.

RHEL provides features that help speed deployment. I am currently learning how to take advantage of those features.

As far as deployment goes, I build a golden image VM and just deploy the images themselves. I don't really use any RHEL tools specifically for the deployment portion.

The solution is constantly expanding and moving into new areas, like jumping into the cloud.

I need more experience with their self-monitoring tools. That is the one area where I feel like I am lacking. I am still using a lot of the stuff that I learned in the Unix realm. I haven't really matured into using the specifics that are being supplied. I am a member of the accelerators team and have been exposed to some of these tools through their lectures. I am starting to play with them a little bit, but I have not fully gone into that arena. So, there is improvement needed on my access to RHEL.

I would rate the solution as 10 out of 10.

Our primary use case is to develop the servers and production. It's pretty standard usage. We have some Docker running but I haven't been involved in those environments very often. It's a standard server on minimal load and we're not using a full load with our GUI interface.

We have multiple applications running on both Windows and RHEL. The database systems are mostly MySQL. There's some Oracle but most of it is MySQL. Dealing with Red Hat is pretty straightforward. I haven't run into issues with it. 

When we were running multiple versions of Java, if patches came out for both versions, we would apply the patches for both versions and usually, that could be downloaded. It was pretty simple to update those. Those are systems-supported patches. With the specific application patches, it's a little different. Normally the application administrators take care of those themselves.

If Red Hat's system is set up right, it improves the speed and performance reliability of our hardware because it doesn't use as many resources as a Windows system.

I like the fact that most of the system configuration is Namespace so it's easy to get to and easy to configure, and most of it still uses text documents. Not all of it's a menu-driven-type entry. I also like the fact that it's a very standard file system layout so it's easy to navigate.

In some instances, it provides features that help speed development. In other instances, it's standard amongst most Linux groups. You can download the main features. The file system is always a big difference. You go from a Debian-based system to Red Hat, so the file system layout is a little bit different. User-based files are located versus system-based files. RHEL keeps everything in one area and segregates it. It makes it easier to go between different organizations and still have the same policies and structure. I do like the new package manager.

It's all text-based, all command line, whereas the minimal load does not have a GUI on it. If you're used to using Windows core servers, it wouldn't be that big of a deal, but going from a Windows GUI-based system to an RHEL command-line-based system is a learning curve for most Windows administrators. A lot of strictly Windows administrators don't even want to look at a command line from Red Hat because the commands are so different from what they're used to. There is a learning curve between the two major platforms.

The application and user experience are usually pretty consistent, but that really depends on the application developer. If they're developing an application, it'll be consistent costs on infrastructure. That's not an issue between the different platforms. User experience is based on how the application developer built it. They're not all in-house and so they developed across a consistent platform. They keep everything pretty simple from the user perspective.

It enables us to deploy current applications and merging workloads across physical hardware and VMs. Virtualization and physical hardware stay consistent. Going to the cloud depends on the platform we use but it'll mostly be consistent as well. The RHEL distribution has been implemented pretty well amongst most of our cloud providers. It's pretty standard now, whether we go to Rackspace, Amazon, Azure, or even Microsoft supporting RHEL distribution. You can go to a Microsoft Azure cloud and have a Red Hat Enterprise Linux system running there. The user would probably never notice it.

For Red Hat, the bare metal and virtualized environments are pretty reliable. The only thing I don't like about Red Hat is that every time you do an update, there are patches every month and you have to reboot the system. Fortunately, it's a single reboot versus Microsoft, which likes multiple reboots, but still, you have to reboot the system. You have to reboot the server. The newer updates have kernel patches involved in them. To implement that new kernel, you have to reboot the system, and Red Hat's best policy and best practices are to reboot the system after patching.

I used the AppStream feature a couple of times. Not a whole lot because a lot of our environment is specific to what we deploy. Normally I would just deploy the bare system, adding features requested by the application administrator, and they'll download the rest of the things that they need.

We have used the tracing and monitoring tools in certain instances but not consistently. We use them for troubleshooting but not every day. We use other third-party software to monitor the system logs and alert on the issues. They will run tracing analysis of the systems. The reason we don't always use it is because of the number of servers I have to deal with and the low band power.

Automation is however you set it up. As for running a cloud-based solution, a lot of it would be automated. Going from prior experience, dealing with it before coming to this company, we did a lot of cloud deployment and it's pretty consistent and reliable and you could automate it pretty easily. 

RHEL accelerated the deployment of cloud-based workloads in my previous experiences. Compared to no other solution at all, it's obviously a vast improvement. You have to worry about Windows. As soon as you bring the server up, it requires numerous patches and it'll take several reboots unless you have an image that is very patched and deployable there. Even then, every month you get new patches. Red Hat patches a lot faster than Windows and requires a single reboot. The speed of deployment is a hazard. It's almost twice as fast deploying an RHEL solution as it is a Windows solution.

I'd like to see more of NCurses type menu systems in some instances. We're dealing with SUSE Enterprise Linux, they have an NCurses menu system. It's a menu system. Even some of the higher-end Unix systems like AIX have some inner menu system where all the configuration tools are right there so your administrator doesn't have to jump through multiple directories to configure files if needed. I like the simplicity of Red Hat because it's pretty easy but having an NCurses menu when you have to get something done quickly would be nice.

I started using Red Hat back in 1996. I've been using it for at least 20 years, off and on. I was hired as a Linux administrator for RHEL 6, 7, and 8, and then I changed my job positions. I'm not actively using RHEL right now.

Unfortunately, we're moving away from RHEL to Oracle Enterprise Linux in the next couple of months.

RHEL is a very stable product. It's been around for a long time now. It's been stable since they brought it out as an enterprise environment. It's usually not the bleeding edge of Linux. That just means it has more stability in the packaging and the repositories. They keep the bleeding edge updates and things out of it most of the time, which means if you have new features that you want to implement, you have to do some finagling to get those features in place. But it does mean the system's more stable, for the most part.

It's very scalable. I haven't seen any issues with the scalability of Red Hat. I've used it in environments where we have a few hundred people to a couple of thousand people. I've never seen any issues with scalability. It's one of the big sell points of RHEL. It's as scalable as Unix.

There are around 500 developers who use it. Web-facing interfaces, it's in the thousands.

If you're using a small environment with no more than around 100 to 200 servers, one or two people can handle most of the RHEL stuff pretty quickly.

If it's a larger environment, then you're looking at staff upwards from six to 15, depending on the environment the product's being used for.

There is a system administrator to perform the initial deployment of a server to the maintenance of the server. Then there are the application developers who develop the application, write the applications, and just manage applications. In our environment, we currently have sysadmins who manage the systems. My job is to manage the actual operating system itself. Then, you have application developers, who develop applications for user-facing systems. The application managers manage those applications, not only the developed applications.

It's being used pretty extensively. It's 1,100 to 1,200 servers on one site. 

We're using at least 85-90% of the features of RHEL but we don't really use Ansible that extensively. Red Hat Satellite server we're using as a primary repository in one site. Based on RHEL, we use most of these features.

We are switching to another solution mainly because a number of databases in use are based on that system. They want to expand that database and some other products that come with switching from RHEL to LEL. That's the main reason. As I understand it, the licensing isn't that different with a more centralized approach, so convenience is a large factor.

We switched to RHEL from AIX because of the developer and the cost. AIX is usually implemented on specific hardware. IBM owned the hardware. So the cost for running AIX is a lot more expensive than running an RHEL solution, which can be run on virtual systems as well as physical systems. And x86 servers are a lot cheaper than a power system.

Open-source was also a factor in our decision to switch to RHEL. Open-source has allowed a lot of development in areas, more ingenuity, innovation, and products than other constricted OSs. My opinion is that when you're dealing with open-source, you have people who are more likely to innovate and create new things. It's easier to develop an open-source platform than it is to use a closed source platform because then you can't get to the APIs, you can't do anything in the system if you want to change things in the system to make your product more available to people.

The initial setup was pretty straightforward. I've even set servers up at home on a pretty regular basis. I have my own lab, so I've deployed it and it's pretty straightforward. With RHEL, the setup is nice because you get a GUI, so any Windows-based user is going to be familiar with the GUI and know what to look at. They can deploy software as needed, right there from the menu. From a TextBase, you can script it to where all you have to do is run a script and it'll deploy the server quickly. It's pretty straightforward.

Personally, I wouldn't be able to speak to the installation. Having a single point is always a benefit because then you don't have to jump around multiple points to download software and to deploy your solution. The only thing about it is with Docker, a lot of times you have to go out to the Docker site to download the newest versions.

If you're running Satellite, it's even easier because all your current patches are downloaded. The iOS is already there and a lot of time is it's a straight script that you can deploy quickly. The single-point install is a good thing.

Depending on what you're running it on and what kind of equipment you're running, it can take anywhere between 20 minutes to an hour. That depends on the equipment.

They had Unix admins on site. They were implemented to bring in the Red Hat environment because of the similarity between Unix and Red Hat.

If you implement Ansible, that's an additional cost. If you implement Satellite, that's an additional cost to your licensing. However, the amount of licensing if you license 100 servers is actually cheaper per server than licensing 50 or 25.

The first one that comes to mind as a real competitor would be SUSE. It's built-in Germany. Ubuntu is a commendable product but I don't find it as reliable or as easy to administer as I do RHEL. A lot of developers like it because it's really easy. It's more geared towards a home-user environment than it is a corporate environment. The support factor for RHEL is good. If you need to call tech support, it's there.

I have used Satellite and Ansible in other environments. Satellite integrates very well. It's built by Red Hat, so it integrates thoroughly and it allows a single point of download for all patches and any software deployments you have. You can automate server builds, if you do it right, and make things a lot easier.

Ansible can tie into Satellite and RHEL fairly easily. It allows you to build multiple types of deployments for multiple solutions, and allows a playbook-type deal. You develop a playbook and send it out and it builds a server for the user. Done.

It would speed up deployment and make it easier to manage. If you had a developer who needed to throw up a box real quick to check something, he could run a playbook, throw up a server and rather quickly do what he needed to do. Then dismiss the server and all resource reviews return back to the YUM. If it was hardware, it would be a little bit different, but if we run a virtualization environment, they return all resources back to the host. So it made matching servers and deployment a lot simpler and less work on the operations environment.

The best advice I could give is if you're going from a Windows environment to an RHEL environment, there's a learning curve that is going to be a factor during implementation management and basic administration. Your company would probably need to hire new people just to support an RHEL environment. Between SUSE and RHEL, the number of people who know SUSE very well in the US is not as high as it is in Europe. RHEL has become more of a global OS than SUSE, though they're both comparable. I would advise looking at what you need it to do and then make sure you have the infrastructure, people, and manpower to support it.

There's a huge number of resources out there. You have sites geared specifically for RHEL administration. I believe IT Central Station has some resources on its site as well. There are Usenet groups and different forums. TechRepublic has a large number of resources as well. There are numerous resources out there to ease the learning curve.

There are a lot of things I've learned over the years using RHEL. Running it as a virtual design environment where you can run multiple servers on a single hardware piece makes it a lot more cost-effective and you don't have the resource depletion as you would have with Windows. Unfortunately, Windows is a resource hog. RHEL can be set up to run very minimally, with virtually no overhead other than the applications you're using to service users. 

I would rate it a nine out of ten.

My customers primarily use Red Hat Enterprise Linux for application hosting and small databases. It is used for hosting Java applications and small web servers.

Cloud-based Red Hat Enterprise Linux deployments provide cost savings. If customers are purchasing a physical server, they need to have a proper setup. They need to have a data center, cabling, and a lot of other things. For cost-saving purposes, they are going for a cloud. As an operating system, it offers the same functionality on-prem or on the cloud.

It saves money for company owners. It helps our customers save money and do things quickly. They can build servers quickly. There is a menu where they can fill in the VM name and other details and attach storage. In ten minutes, they have a server ready.

I am Red Hat certified. I train people in corporations and educational institutes. Red Hat's material is very good. Their testing system is awesome. If someone is certified in Red Hat, you know that they know it well. There are millions of videos on YouTube, but they are not always updated. On the Red Hat site, the documentation is very clear. You just need to focus and study for two to three months to get certified.

Nowadays, delays are common with their support, and it often takes time to get assistance from experienced engineers.

I have been using Red Hat Enterprise Linux for seven to eight years.

Red Hat Enterprise Linux is an excellent product, and its stability has improved significantly over time. It can operate for extended periods, like six months to one year, without issues.

Red Hat Enterprise Linux scales well with increasing user demands or infrastructure size. It is easily available and efficiently adapts to varying needs.

Most customers host medium-sized applications on the cloud. Storing a big application can lead to higher costs.

The technical support from Red Hat has declined over the past four or five years. It could be because there are not many skilled people. When we raise a case, it is attended by junior people or new people, which wastes two to three days. We might even have to raise the severity of the ticket. However, when senior people take ownership of the case, the support is awesome. They give proper support. This was not the case earlier, so whenever we raised a ticket, we got an immediate response from Red Hat.

Positive

The initial setup is smooth.

We have Cloud-based deployments. We are using AWS, GCP, Azure, and other cloud platforms. We also have on-premises deployment. Some customers also have a mixed deployment with the cloud and on-prem but in such environments, I have seen problems in terms of performance. For example, if my database is on-prem on Red Hat Enterprise Linux, and I am storing my application on the cloud on Red Hat Enterprise Linux, whenever someone hits the website, there will be latency issues. I sorted out such issues for a customer. I suggested they migrate their server from the cloud to on-prem because their database was quite big. With a mixed setup, they were having a lot of issues in terms of performance and storing data. It was very slow. After they moved it on-prem, it was much faster. This is not a Red Hat-related issue. From the operating system side, no improvements are required. However, cloud providers need to improve their facilities.

For patching, I use Red Hat Satellite, and for configuration, I use Red Hat Ansible. Leapp upgrades are also awesome. A month back, I upgraded Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9. I created detailed documentation about the procedure. There were about 14 steps. It was straightforward.

With Red Hat Insights, we can see the security threats. Red Hat Insights is integrated with Red Hat Satellite. It will be helpful from the patching point of view. It lets you do subjective analytics of servers.

I did some research on pricing a long time ago, and at that time, it was much cheaper than Windows. I do not have current details about pricing, but it is affordable.

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