Red Hat Enterprise Linux (RHEL) Reviews

I use Red Hat Enterprise Linux for my infrastructure and OpenShift primarily for its Kubernetes capabilities.

I wanted to build infrastructure based on Red Hat for commercial distribution for data centers.

The built-in security features significantly simplify risk management and compliance maintenance for on-premises deployments. The well-documented and regularly updated features make it easy to find solutions to any issues we might encounter.

Red Hat Enterprise Linux boasts a top-notch knowledge base. Compared to other distributions, it offers comprehensive information for each iteration of the operating system. This information is categorized by Red Hat Enterprise versions – seven, eight, nine, and so on. Likewise, the documentation and knowledge base are further organized by platform versions, like 13 and 14. This clear organization makes it easy to navigate and find the information needed for troubleshooting or understanding specific features. Given the ease of use and depth of content, Red Hat's documentation gets an A+.

The uptime has been reliable, minimizing infrastructure impact.

Red Hat Enterprise Linux's security advisories typically notify system administrators of potential vulnerabilities, allowing them to prepare for patching easily.

The most valuable feature is the OpenShift platform.

The high cost of Red Hat Enterprise Linux has room for improvement. The high cost in terms of a platform is problematic.

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

Red Hat Enterprise Linux is stable. 

The scalability of Red Hat Enterprise Linux depends on its deployment environment. In a bare-metal setup, scalability is directly limited by the hardware server's capabilities. Similarly, virtualized deployments are still constrained by the underlying hardware resources. However, when RHEL is used within OpenStack, the Red Hat OpenStack platform can manage both virtual machines and workflows, enabling horizontal scaling by adding more nodes to the OpenStack cluster. In this scenario, the number of chassis in the infrastructure becomes the primary determinant of RHEL scalability.

The technical support is responsive and efficient, with a streamlined ticketing process. When troubleshooting hardware issues, their technicians typically check relevant files to diagnose potential problems with the chassis or related components.

Positive

I previously used Canonical in other open-source projects and pushed for a switch to Red Hat because of my familiarity with it in past projects. My current employer does not utilize Red Hat Enterprise Linux because of the high cost.

The deployment complexity is based on the project and the architect of the particular solutions. There are scripts that we can use to perform the upgrades or migration. The number of people required for upgrades or migration depends on the size of the solution. For a small solution, we can automate and don't require any people. If we are using a third-party solution already in place we can achieve the same goal without a large team.

The combined cost of implementing in hybrid and cloud environments to fulfill all our client's needs can be considerable.

There are only three distributions that offer commercial support. Red Hat Enterprise Linux, Canonical, and SUSE. It all comes down to the cost for each organization.

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

The amount of people required for Red Hat Enterprise Linux maintenance depends on the type and size of each project.

Red Hat already provides tools to maintain up-to-date migration plans. These tools can not only identify which components require upgrade but also preserve any already installed elements. Additionally, Red Hat offers a web-based solution for managing upgrade processes if required. However, we can choose alternative options: implementing the solution ourselves or employing open-source software for upgrades. I see no significant challenges with utilizing Red Hat tools for the upgrade process.

I recommend evaluating all the available solutions that offer the tools that Red Hat Enterprise Linux offers and comparing their functionality and cost to avoid issues after purchase.

We had a lot of IBM AIX servers. We migrated a lot of them to Red Hat Enterprise Linux. We have a lot of VMs, and we have a few physical servers. Currently, we are moving all the Red Hat VMs to the cloud. There are 1,600 to 1,700 Red Hat VMs that we are currently running.

The main benefit is that it can be easily recovered and easily restored. It is on the VM. We can easily restore every image that we back up on the VM. If something happens, we can easily fix it. Support and maintenance are easy. The most common issues that happen with Red Hat Enterprise Linux are password restore issues. We can go and restore the passwords through the single-user mode. This feature is well-developed and good.

We are using Ansible for the most automations. We can push everything through Ansible. We are moving towards automation to make sure our system can be easily maintained, and we can recover, restore, and do the things that we want. We have 1,600 to 1,700 servers. We have Ansible Tower, and we have a few satellite servers and a lot of capsules to support Red Hat servers.

If anything is supported by Red Hat Enterprise Linux and the feature is available in Red Hat Satellite, we are able to install it on Red Hat Enterprise Linux. We are using Red Hat Satellite to install all the patches and all the packages, so if a feature is available, we can easily install it if it is supported.

Red Hat Enterprise Linux has built-in security features for simplifying risk reduction and maintaining compliance. We are working with most of the security environments. Security is our main concern. We have zero tolerance when it comes to security. We are able to apply security rules and regulations within the Red Hat environment.

We are using Red Hat Enterprise Linux 7, and we normally look at how it can easily support the system. With Red Hat Enterprise Linux 7, we have a high-security system. We have a lot of features there. That is the main thing, but currently, we are moving from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. 

Red Hat Enterprise Linux Leapp and Red Hat Insights have been useful. RHEL Web Console is also helpful.

We have access to the Red Hat knowledge base. We have frequent meetings with Red Hat. Red Hat partners provided us with all the information and any kind of training.

We are using the features that are available with Red Hat Enterprise Linux and Ansible. As such, there are no specific features that we are looking for. 

We have frequent meetings with them. We have had some issues on the application side and the OS side for which we opened cases and discussed those concerns and questions in the meetings offered by Red Hat.

I have been using Red Hat Enterprise Linux for almost 10 years.

Upgrades and migrations are ongoing processes to stay current. We are a big company. We always have migration going on. We always have the build process. Red Hat's presence keeps increasing in our environment. We are going to have about 2,500 Red Hat Enterprise Linux VMs in the next year.

If there are any concerns, we have a meeting with Red Hat, and they provide the required support. When we have any concerns or questions, they answer them. It is easy. I would rate their support a nine out of ten.

Positive

We have probably seen an ROI. Red Hat is getting better every day. 

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

We're using the product to test operating system stability and verify that it runs on the hardware that Trenton Systems produces. If it passes testing, it becomes a validated operating system that we can sell for the server. We plan to offer Red Hat in the coming months to anyone purchasing systems from our company.

The solution’s security feature is the most valuable feature for my company. We offer OS to military or government agencies. For these sectors, security becomes one of the highest priorities, especially the ability to wipe everything out if anything becomes compromised. Red Hat does a great job at that.

The product should be made more accessible to someone who isn't experienced with Linux.

I have been using the solution for four to five months.

The solution is very stable. Compared to many other OSs we test for our company, Red Hat Enterprise Linux has not crashed out on me or given me any problems. Anytime something goes wrong, after some research, I find that it's going wrong because I'm doing it wrong, not because the OS is fighting me in any way.

I haven't used support where I'm emailing or speaking to someone directly, but I've used a lot of the online support just by looking at different user guides, health guides, and things like that. Everything is really well documented. 

Sometimes there are posts about similar issues but with different remediation based on different circumstances. You might have the answer open in a tab, but you've got nine tabs open to find the right answer.

Positive

I have used Ubuntu, CentOS, openSUSE, and Mint. Red Hat Enterprise Linux definitely has an edge in security and the ability to control what the user at the end stage is doing. However, it is difficult to learn.

The licensing makes perfect sense for the number of features you get with the operating system.

We test Red Hat Enterprise Linux 9, the latest version. We do backtesting for versions 7 and 8 as well. The product is very secure. It took me a while to wrap my head around the whole Subscription Manager system and understand how that worked. Even at a base level, it provides a much higher level of security and the ability to take remediation steps if things go wrong. You can shut the whole system down and bring it back from the ground up.

From the keynote, it looks like steps are already being taken to make the solution more accessible to any regular user. 

The product does a really fantastic job of reducing the overall risk to the user. If a user is doing something they’re not supposed to be doing, it's very easy for the system administrator to walk them out of doing it. As for maintaining compliance, if a user is only meant to have specific packs and is only meant to perform specific tasks, it's very, very easy to lock it into only being able to do that one specific thing.

Most people in IT enjoy a little learning. Everything I've done so far with Red Hat has been installing, setting up the account, getting everything registered, and then worrying about testing to validate. It is difficult to start with, but the more you learn about it, the easier it gets. The more I use it, the more capabilities I find within the system.

Overall, I rate the product a nine out of ten.

Internally, we use Red Hat Enterprise Linux for services and for applications that we run, especially Linux based-applications. We also have SAP solutions, which we sell to the customers as a total solution with Red Hat, SAP HANA, and also for our own cloud-based SAP HANA, which is under Red Hat's operating system.

Red Hat Insights is quite an interesting and valuable feature. Lately, we used the malware scan feature. The Cockpit feature and web interface were quite helpful. We have also begun with OpenSCAP, which used is to harden the operating system's security features.

The first area for improvement is documentation, and I consider it since I have been working in IT for more than twenty-five years. For twenty years, I have been working with open source, and I see that the documentation is lacking, so it needs to do more work on its documentation part. Most open source and upstreams from Red Hat products work from the open source solution and have better documentation than in the actual Red Hat products.

New products need better documentation. The websites also have a single sign-on to get you from one side to the other. As a partner, I had a problem finding out how I needed to connect and to which side of the solution. I consider myself an expert user of the internet and websites, but going from one side to the other, was quite problematic.

I have been using Red Hat Enterprise Linux on the cloud for four to five years at least. My company has a partnership with Red Hat, and so we have our own licensing for the product. We have customers whom we manage, and they purchased the licenses on the go from the cloud provider. We just sold them the managed services. But mostly through us, we should be selling the licenses.

It's a very stable product, and that is actually the reason we are forcing or pushing customers to go with Red Hat Enterprise Linux.

The solution is scalable.

I rate the support a seven out of ten. The support is knowledgeable but slow if we have to get answers.

Neutral

We use Red Hat Satellite for managed services for our customers. And, of course, we use a product of Red Hat Enterprise Linux for servers. We started with OpenShift in the lab at the beginning, but now I'm beginning to produce it for our own services. So, now I can offer these to the customers.

One of the discussions in my company at the beginning of this year was to see if we could test our services on-premises for the virtualization, specifically for the KVM virtualization. But since it was not approved, we'll have to see the next step.

I have worked with other open source distributors. I have worked with SCO-Linux and Unix, which is the base of Linux. I didn't personally make the decision to switch. The company decided to switch since we are partners, and we are focusing on putting in the best efforts in terms of the partnership and customers we have with Red Hat.

The solution is deployed on both on-premises and the cloud. We have customers on the cloud server platform where we run their network, and we manage through Satellite. We also have it on-premises.

I was involved in the deployment of the solution. We created some automation, so the setup phase is straightforward. We use templates for all of those, but to manage the templates, and what it will include, we use external tools to make it easier for the deployment automation.

Regarding deployment time, it can be done in seconds. It also depends on what application we are speaking about since for an OS or more difficult solution, like Red Hat Satellite, you need more time.

I have seen a return on investment, especially considering the time taken to resolve the problem where we bought some support from Red Hat.

Regarding the prices, the new changes are actually not bad as it works for enterprise solutions. But it could have some other options for super solutions for the students in colleges, and they could actually win more customers from that. Of course, we have the test licensing and all that for the partners, where it's very useful for us to be able to test more of the products. But to win more would be much easier for us also if they introduce special pricing for students, universities, governmental institutions and all that. Most probably there is a price for them, but we haven't got that information. Also, Red Hat sometimes goes directly and not through the partner, but I'm not an expert.

I wasn't the one to make a choice, but I think my company evaluated other options, and it was their choice to go with Red Hat.

My company is a private cloud company. Mostly, we have our own private services, providing private cloud services to the customers. But we also provide public clouds like Azure and some Amazon clouds.

Regarding resiliency, it is a good standardized OS with stability. But sometimes, it is a little slow in reaction to problems that might appear. For example, we had this big Java Log4j bug where their reaction was very slow compared to other distributions. Of course, they found the solution when they had it, but it was quite a slow reaction. In general, it's a very stable OS.

Regarding how easy or difficult it is for you to move workloads between the cloud and your data center using Red Hat Enterprise Linux, I don't have any solution for that. I have to migrate it manually right now.

Regarding the cost-saving capability of the solution, I would say that it is possible to save on costs because of the automation we use through Red Hat Satellite for maintenance and how we have managed automation, time to spend on the service, maintenance, test, problems, etc. So, you can say that it's been a cost-saving procedure.

I rate the overall product a seven and a half out of ten.

We're the largest financial institution in Africa, and we use various operating systems and technologies to achieve typical financial service goals. In the past, we were an ION-centric shop. However, in the past decade, we've been increasingly leveraging Linux's agility compared to traditional Unix operating systems. 

Generally, we deploy by cloud, but we use RHEL on-premise in our data centers and prefer SaaS for infrastructure as a service. Our primary cloud providers are AWS and Azure, and we also use smaller third parties for niche environments.

RHEL is spread across virtually all elements of the institution, including headquarters and various locations on multiple continents. In my environment, it is part of a global trading settlement system. 

The rollout for this particular solution was probably about 250 users of the application running on the initial RHEL. We're a global bank, so the user base is much larger worldwide. Users include business and feature analysts, engineers, and project managers. Our infrastructure engineers were the ones pushing for a switch to RHEL, followed immediately by application engineers.

RHEL enabled us to move away from reliance on ION. We're free to choose the best-of-breed solution at any given time while keeping the cloud-agnostic infrastructure at the center of our deployments.

Our operational expenditures decreased, and RHEL made our teams much more flexible. With RHEL, we can have multiple copies of an OS without making annual plans to license and acquire.

The benefits were instant from my team's perspective. For example, we were immediately more flexible and able to scale rapidly. However, if you're looking at it from an executive point of view, the time to value depends mainly on the product and the scale of the endeavor. It might take a few years to reap a return. Ultimately, you will see the financial benefit, but that's somewhat difficult to quantify in the short term. 

I don't think that it's enabled us to centralize development, but it has perhaps increased the breadth of development possible on our applications. In that sense, more development can be centralized on the operating system, but that's more of a byproduct.

We outsource cyber security to other teams, so I can't comment in-depth on RHEL's security features, but I can say it enabled us to understand our security posture more efficiently. This wasn't always possible using an AIX or Solaris in a more centralized fashion. The feature set is maybe not as important as having a single pane of glass and a single configuration to apply across our systems and infrastructure.

RHEL made life a lot easier in terms of compliance because you can more accurately gauge yourself against industry benchmarks with the tools provided and identify your shortcomings. You can interrogate what you've done through research from multiple parties rather than just a single source of truth, which may not be true.

You can compile and run applications on any operating system, but RHEL's advantage is flexibility. It is more supported and supportable in the enterprise sense than Ubuntu or perhaps a smaller distro, but it's also flexible enough to easily transport from platform to platform: ISA to ISA,  production to development, and vice versa. That led me to embrace the switch to RHEL from other operating system variants.

RHEL offers more portability than any other OS flavor apart from perhaps Ubuntu Linux. As a large bank, we run on IBM's architecture. We run Power, Spark, and Oracle x86 across multiple environments. It lets us choose the right environment for the application, which is essential from an operational efficiency perspective. These days, we're all trying to cut heavy infrastructure and move to lightweight agile infrastructure. There isn't a better option in the production world than Red Hat.

There needs to be a broader understanding of the RHEL suite's nuances like how the versioning works and implementing it on various kinds of infrastructure in use across the development landscape. There needs to be more training and education. It's difficult when you have a roadmap to deal with, but it is possible. 

Large application vendors may not have certified RHEL, or they have certified an older version. Most of the large application vendors are unfamiliar with the versioning that RHEL introduced, which I strongly support. They will support a given sub-version up to a point, not realizing that the sub-versions are essentially additive. 

This can be a real frustration when you try to deploy modern infrastructure. It allows tremendous flexibility because we can try things out across the cloud, virtual, and physical, but that's not always where the issue is. It's a matter of educating the engineers and developers on our side or enterprise vendors on the other. 

The licensing could also be simplified. While it makes sense from a theoretical perspective, it's a challenge to explain to the procurement team. Those with some technical expertise can understand how our licensing model works. However, it's still tricky because Red Hat is so different from traditional operating systems. It's another barrier when I'm trying to deploy it in an enterprise environment.

In terms of feature requests, I would point out that our company tends not to operate on the bleeding edge for obvious reasons. We look at what has already been released to define our roadmaps. There's nothing in particular that I would say needs to be included. However, I would like to see Arm playing a more prominent role in the cloud infrastructure and enterprise physical data center spaces. Red Hat supports this, but I haven't seen a clear roadmap for how that support should evolve within the Red Hat operating system environment. 

I have used Red Hat Enterprise Linux for more than 10 years.

RHEL's stability is good. 

RHEL is highly scalable and we plan to increase usage. 

I wouldn't rate Red Hat support as less than eight out of ten because I can't think of anything negative to say. I can't think of a time when I haven't been able to get it. Also, because RHEL is global and Linux is open-source, you can typically get the support that you need through research forums and the knowledge base. It's seldom necessary to involve third-tier support within RHEL.

Positive

We still use other operating systems. We've used just about every solution you could name in conjunction with RHEL. We also deploy Ubuntu. In some cases, our application vendor requires us to stick with a given solution. Sometimes it's AIX or Solaris, but mostly we can override that and move to RHEL. Red Hat is now standard for most future enterprise deployments, and we run RHEL on mainframes too, but in a very limited fashion.

The setup was complicated only because the applications we were trying to run were not certified to run on RHEL. It was version 6.8, so we worked with major global vendors to add the certification for the versions we were trying to run. That was the complexity. The application always worked beautifully, and the performance was excellent. It wasn't a question of getting the development to work; obtaining an issue of getting certification for the platform, which is required for any financial institution.

From a development perspective, we proved the concept and ran a mirror of production and development to demonstrate the improvements in OpEx and performance. Getting it up and running in parallel was the key to getting it all to work correctly, and it was instrumental in convincing any dissenting voices of the value. 

The deployment took less than three months, but the certification took nine.
The team supporting the first application numbered around 50, and the small group involved in the initial switch had about eight people.

The entire application is run exclusively on RHEL, so the whole operation team is probably around 40 or 50 people. It's worth adding that our overall group runs about 20,000 servers, so it's challenging to say overall what the RHEL footprint is.

After deployment, RHEL requires maintenance to keep the solution up to date. Security requirements tend to be more prohibitive or less encouraging of change. It's a question of changing mindsets and explaining that something doesn't have to be legacy-tested to update. The security benefits of updating are more critical than testing to ensure the update hasn't introduced more flaws.

I don't have the data, but we have significantly reduced operational expenditures since switching to RHEL. It was a reduction of more than 10 percent. 

The licensing is tricky to understand. Enterprises want to be beyond reproach when it comes to licensing. We would rather over-license than under-license. However, that can be complicated with a high-performance development team who may need multiple operating system instances or want to experiment with spinning up many machines to see if something works or sticks. 

We don't necessarily need support for those. Our procurement team is confused if we need a license for an instance that was only up for 15 minutes on Thursday. We need to make sure that we always have sufficient licenses. That misunderstanding of how cloud development works can sometimes slow down development. It inhibits the growth and success of Red Hat Enterprise Linux globally. So more education around that would be beneficial or at least will provide more clarity.

RHEL's total cost of ownership is difficult to quantify, but it's almost irrelevant. In cases where you don't care, you can always use an open-source OS. In other cases, you need the support and certification that comes with something like RHEL. I do not believe RHEL has any competitors in our use case.

I rate Red Hat Enterprise Linux nine out of ten. My advice to prospective users is to try RHEL out and see if your application works. In the long run, the benefits will outweigh the time and effort spent migrating. The important thing is to ensure you run programs in parallel so you can accurately evaluate the benefits and make a case for switching.

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.

We use Red Hat Enterprise Linux due to its robust security features, which are essential for securing e-commerce transactions and monitoring our Linux servers. Additionally, its flexibility allows for deployment across a range of devices, including HPE and Dell.

Red Hat Enterprise Linux offers robust provisioning and patching management capabilities, ensuring efficient system administration and security.

I am delighted with Red Hat Insights and recommend this feature to others.

Since using Red Hat Enterprise Linux, I have found it to be very secure.

Red Hat Enterprise Linux has reduced our downtime by about 60 percent.

Red Hat Enterprise Linux aids in achieving security standard certifications by providing a secure foundation and tools for compliance with various security frameworks.

The most valuable aspects of Red Hat Enterprise Linux are its flexibility and security. It allows us to manage servers independently and ensures security for any device used.

The system roles feature is good.

While Red Hat Enterprise Linux offers robust security features, continuous improvement is crucial to ensure a secure environment and prevent potential losses.

I have been using Red Hat Enterprise Linux for about six years.

I rate the stability of Red Hat Enterprise Linux as seven point five because sometimes it takes time to reach support for assistance.

I rate the scalability of Red Hat Enterprise Linux as eight. It is satisfactory in terms of scalability.

The response time could be improved as sometimes it takes too long to reach out to them.

Positive

The complexity of deployment can vary based on familiarity with Red Hat Enterprise Linux. I found it to be complex.

Red Hat Enterprise Linux can be expensive, but its cost is not a deterrent for many organizations willing to invest in its stability, security, and support ecosystem.

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

We have 80 percent of our environment using Red Hat Enterprise Linux. A team of around 40 uses Red Hat Enterprise Linux to manage over 3,000 servers in a big environment.

We perform weekly maintenance on Red Hat Enterprise Linux.

We do updates, upgrades, and migrations on our Red Hat Enterprise Linux servers.

Based on my experience, I recommend Red Hat Enterprise Linux, particularly to those seeking a highly secure operating system.

The main use case is generating golden images. All the deployments of operating systems and virtual machines on the servers are based on the golden image. The developers and providers can run all the applications on top of those.

Whenever we need to remediate any vulnerabilities, patches are available. These patches are not only for current exploits but also for back-porting for bug fixes and security fixes. These patches are available from the most recent versions to the specific version that we are using.

Red Hat Enterprise Linux has enabled us to centralize development. We have a golden image of the operating system. That golden image sets the standard for all the security policies that we are applying to it. For example, the partition scheme and the best practices that we apply to the golden image are the starting point for all the developers to start working with all the applications and also executing appliances or applications from providers.

We are using Red Hat Enterprise Linux with Podman for containerization projects. Red Hat offers what is called UBI or Universal Base Image. That image is already configured to be secure and have good performance. To start working with containers, we just have to pull UBI as a base for our images and start working on those. It has impacted our containerization project because instead of using Docker, we can use Podman. There is a common container image that is used by the majority of the customers, but I forgot the name of that one. Instead of using that, which is like a very minimal image, we are using UBI because it is already secure. It has the majority of the benefits of our Red Hat Enterprise Linux image but in a container image.

There is portability of applications and containers built on Red Hat Enterprise Linux for keeping our organization agile. That is a very good option to have because you do not have to worry about the underlying system. You just have to worry about your application and have the application running on top of your image based on UBI. It is going to be so easy to have the application running either on a machine with Podman or have the same application running just on top of OpenShift. It is so easy to move a container-based application that can be executed on top of Red Hat Enterprise Linux with Podman or on top of OpenShift. 

Security, packages, and updates are valuable. There is also the possibility to do unattended installations. This way you can define how you want the installation to behave and be configured whenever you do the deployment.

One of the best features is having a tool called OSCAP, which is a tool that is going to allow us to apply security profiles to the golden image. This way, all the security features or policies can be applied in real time. This way, we can follow all the policies that are defined by our security teams.

There are not a lot of areas to improve because the majority of the time, Red Hat is constantly improving it. The only area would be in regards to being capable of running on other architectures like ARM. They are about to release a new version that is available to be executed on ARM architecture.

We have been using Red Hat Enterprise Linux for about a year.

It is very stable.

It is scalable. We have plans to increase its usage.

It used to be better. It is still good as long as you can get in touch with a level 3 support engineer. If you have a trained engineer who helps you with what you need and who understands how to ask for specific details of what you need, you should be good. But, unfortunately, if you start with a simple detail of what you are experiencing and what kind of help you need, you will receive the same response. For example, you are pointed to a knowledge base article, and that is it. The support engineer is supposed to help you with your issue or request, but unfortunately, that is not happening anymore. It used to, but I understand.

We are looking for a support engineer to go all the way. The only way for you to contact support is via the support case system or page. After that, you interact through the ticket or email. You do not have a chance to have a call. If we have escalated a case, it is usually better if you have a person for a proper understanding and proper advice on what you have to do and how to resolve the issue. It could be that you need a new product, subscription, or service, but you do not know that.

Neutral

When I got into the company, they were already using Red Hat Enterprise Linux, but back in the day, I used to have HP-UX. That was a very ancient system. It was Unix-based. It was a proprietary solution. HP-UX was a platform licensed based on the old Unix code that was tightly integrated into hardware built only by Hewlett-Packard. You could not run HP-UX in any other place. You could only run it on hardware created by Hewlett-Packard. The intention with that was to run only on the Itanium architecture, whereas Red Hat Enterprise Linux can run on x86 architecture. It is also open-source.

We have it on-premises. It is in different locations. We are following a strategy to publish the images of the operating system. This way, multiple teams can grab the images and have their own procedures to deploy within each separate environment. We have multiple teams working on developments and they need a base image to start working on all the development stuff. Because they are all independent teams, they have access to a single source of image. This way, they can start working on further customizations and whatever they need.

We implement it in-house.

The ROI is in terms of the time that I have to invest in doing customizations, applying security policies, and fixing the supply to the system, wherever I need those.

The reason for going for Red Hat Enterprise Linux is to improve the time to market. It is so easy to just generate a new image. We can configure it with all the security features and all the libraries and packages we need. We can also configure it with the ones requested by developers. We can do all of that. It is so much easier than what we can do with Windows, for example.

It is very straightforward. We do not have to think much about having to get all the subscriptions related to the Red Hat Enterprise Linux fleet that we have because all the subscriptions came in pairs of CPUs or even for an entire bare-metal server. That way you can partition your bare-metal server into multiple virtual machines, and then you are covered. As long as your bare-metal server is covered, you can roll out any number of virtual machines on top of it. It is very easy to get subscriptions for your bare-metal server, and you can utilize whatever you want.

We evaluated operating systems or Linux distributions created by the community or run by the community only. We evaluated them mainly because of costs.

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 they would not have the same team supporting all the operations and all the critical features and patches that they receive with Red Hat Enterprise Linux. They can go with one of the clones, but unfortunately, at the end of the day, the clones are going to deviate from Red Hat Enterprise Linux. With Red Hat Enterprise Linux, you can also create support cases to receive back-ported bug fixes and security fixes, and you get very cool features such as Insights, Satellite, or system roles provided along with Ansible. 

We are currently not using Red Hat Insights but that is an awesome tool.

Overall, I would rate Red Hat Enterprise Linux a ten out of ten. It is an enterprise Linux distribution. It was one of the first distributions to focus on the enterprise. There are others, but Red Hat is the main contributor to the Linux ecosystem. Because of that, it is so stable. It has proper support. It also provides the Linux ecosystem with new features and enhancements.