Red Hat Enterprise Linux (RHEL) Reviews

We use Red Hat for all sorts of use cases. This includes everything from running applications and databases, or the combination thereof, to building software for products that we use for embedded design.

My company has several RHEL implementations deployed in the field, including versions 4, 5, 6, 7, and 8.

RHEL allows us to run multiple versions of the same application with no problem. We have specific databases and specific versions of them running for the support team, even though some of them are not in support. It has lots of features for things like containerization.

We use a fair bit of Red Hat including other products such as Red Hat Satellite, Red Hat Insights, Red Hat Ansible, and Ansible Tower. We have also attempted to look at an OpenShift PoC. Red Hat seems to be doing a great job integrating their products. For instance, Satellite 7 will finally have all of the Puppet functionality Ansiblized. Overall, they're doing a great job integrating their stack to help make it better.

Having this integrated solution approach provides us with greater operational excellence because we can see what somebody is building. We have the environment captured and have visibility about what went into it for repeatability, reproducibility, scalability, and lots of other benefits.

The most valuable feature of RHEL is that it's well supported. It's a good Linux platform.

RHEL Smart Management gives you access to Satellite, which helps you do automated kickstart deployments. Satellite has a lot of control, giving you the ability to control content promotion, content YUM updates, caching, et cetera. You can have as much or as little overhead in compliance control as you want.

In terms of running and using applications, Red Hat is consistent regardless of the underlying infrastructure. It's implemented on VMware, Proxmox, KVM, and Hyper-V. Whatever underlying infrastructure you put it on, it's still Red Hat, which is great.

We use this product's built-in tracing and monitoring tools such as syslog and SAR (system activity reporter) to provide us with greater insight and visibility into what's going on.

I would like to see improvements made to the subscriptions and management of them.

I have been working with Red Hat Enterprise Linux (RHEL) since 2013.

Red Hat is a super stable operating system.

RHEL is reliable across environments including bare metal, virtualized, hybrid cloud, and multi-cloud. I do not worry about things on Red Hat most of the time, at least not from an operating system perspective.

This is a very scalable product.

From an administrative point of view, we have a team of 10 Linux admins but as far as consumers of the environment, we probably have between several hundred and 1,000 users. It is difficult to estimate precisely.

We have approximately 1,200 VMs with Red Hat Linux registered. We are going through divestitures so our company will be growing and shrinking our usage. We really don't know what next month will look like and whether these systems need to be replicated, duplicated, de-commissioned, et cetera.

I assume that in the future, we will maintain something close to 1,200 hosts.

Red Hat support is great, and I would rate them an eight out of ten.

We have vendor support for our platform that we support internally. We don't often use Red Hat support but it's nice to know that they're there when and in case we need it. It's a good product, so we hardly ever actually have to open support tickets for Red Hat Linux, specifically.

Positive

We also use SUSE Linux and have some implementations that come packaged as an appliance from various vendors. We also have some Ubuntu requirements but those are not managed by the internal Linux operations team.

The initial setup is straightforward. You start off by putting a disk in and specifying what partitions you want. Then, you can opt for a minimal OS or something with more features, such as a web server OS. Once you select what you need, it does some initial configuration and setup.

We always use a minimal configuration and build up from there. Our deployment process is a mix of legacy, where we do a manual install, versus a fully automated installation using Ansible.

For an end-to-end build, we normally take about 20 minutes. That's going from a bare minimum template to all of our security, InfoSec requirements, register to Satellite, register to Insights, etc. 

In summary, the installation is as straightforward as it can be for Linux OS.

We purchase our subscriptions directly from Red Hat and handle the deployment internally.

This is not a cheap solution but it gets you the support if you ever need it. That said, it's nice to know that having Red Hat support is there but it's always stable so I hardly ever use it.

The single subscription and install repository for all types of systems makes it simple to purchase and install Red Hat. We had Red Hat x86 before this, and when we wanted to purchase the newer version, their system made it easy to complete the purchasing and installation processes.

There are a lot of other architectures available that we don't use, such as RSCT. They can be obtained from the repository but aren't applicable to us.

In addition to the standard licensing fees, we pay for Smart Management. This gets the Satellite and Insights features, which I recommend.

Overall, their subscription, process, and repository make for a streamlined purchase and installation process.

We did not evaluate other options before choosing Red Hat. This has been the operating system in place since before I started with the company.

One of the new features in RHEL version 8 is AppStream. We're still doing our RHEL 8 deployments and although we've started using AppStream, we haven't gotten very deep into it. Its use is on a very limited scope. RHEL 8 is about halfway through its lifecycle and we're still trying to see how it works.

When it comes to the deployment of cloud-based workloads, this solution helps to automate activities. We are just starting our cloud journey and as such, we currently don't have any cloud-based workloads. However, we plan to, and my understanding is that it will be much easier using Red Hat Gold images for Azure, AWS, etc.

My advice to anybody who is implementing this solution is to automate as much as possible. Overall, I think that this is a good product. I'm a pretty big proponent of Red Hat and in fact, as we speak, I'm wearing a Red Hat RHEL 8 shirt. 

I would rate this solution a nine out of ten.

We use it for databases and applications. In the new model, we keep databases separate from applications. Currently, about 90% of our operations are running in Red Hat 8. Some systems are still on Red Hat 7, but those will be migrated off by the beginning of next year.

It's been great since we have it. It's been reliable and fast. We keep all the security agents, and we've been taken care of right away, and that's the improvement in our company. It's with the new RHEL. There's always something new, something good that works for us. 

Moreover, we might need to move workloads from the cloud in the US to China in the future.

As we're migrating and doing the Elite upgrade, which is an in-place upgrade, we find it great. We use it for databases, and we're testing it for applications. Some applications don't work, but some are functioning well. So far, it's been a positive experience.

Since I'm more focused on migrating, Leapp is awesome. We are able to do something that will work the way it's working.  There are no issues or breaks.

RHEL's knowledge base is great. It's very good. Especially when you try to open a case, it gives you all the options you need, so you don't have to wait for the case to be opened. You can get all the information you need right there.

Moreover, I am in the process of testing Leapp and Red Hat Insights. And then create our images from there rather than create MIs.

At the new company, we've been using it for three years. At my previous company,  we used it for over five years. Personally, I have been using it for almost eight to ten years.

We often have to go through people who have the same labels as us and who have the same knowledge base articles as us, which takes time. But they do it first; it's searching the knowledge way that I search. That I can do. That takes the time before. They do the payment. They sent me exactly what I had already found. And then we can go to the next level. That is taking a little bit more time that we can be a little bit better. So, the initial step of the support process could be improved. 

90% of people who open those bases are administrators who already look on the Internet for all these knowledge bases. So by the time we get there, we're gonna get the knowledge base back. And that's not helpful. 

Positive

I used to use HPUX and Solaris. We switched to RHEL because HPUX started looking like it was going away, so we started moving to Red Hat. We thought it was our best option. We tested different flavors of RHEL.

When it comes to provisioning and patching, we have a satellite server. We use a lot of Ansible. We are getting used to Ansible and Satellite servers. 

The initial setup wasn't complex, but since we wanted to make it easier to use, it became harder to make it work the way we wanted. Not out of the box, so we can just build a server that is ready to be deployed right away without any more interventions.

We use RHEL with AWS because it's easier for us to maintain since we create our own AMIs and we update that as we need it. So we don't need to follow their schedule until we get it more secure and more reliable for us.

Overall, I would rate the solution a ten out of ten. 

It's pretty much everything that we have. We don't have a lot of Windows in our environment.

I've been using it a lot for several years. In the past, I ran a small web hosting company, and we used it for web servers, mail servers, FTP servers, and other things like that. After that, I was in casinos, and those were mostly Windows, but here, it's a lot of Linux, and it's all Red Hat. In my team, we just build it and make sure it keeps running, and the application teams do what they do.

We use Red Hat Enterprise Linux on-premises. We support the in-house server-based things, and we have another team that supports all the cloud-based things, so I don't have a lot of visibility into the cloud.

In terms of the version, we're trying to phase out version 7. We just brought in version 8. Our Satellite is a little bit behind. By the time that gets caught up, our version 8 should be a little bit more solid, and then they can start testing version 9.

I haven't been on this team for a very long time. I've only been on this team for a couple of years, and it was already in place. In the past, we used it to get the stability and the support that we needed because, for a web hosting company, it was either IIS or Apache, and that was back in the NT days, so obviously, we went with Apache. I find it a better server operating system, so that's what we use.

I don't use it in a hybrid cloud environment, but my organization does. I like its built-in security features when it comes to simplifying risk reduction and maintaining compliance. All the firewall features and iptables have been fine for me. SELinux has been great for me. With the hosting that we used to do, SELinux was great because we had to share files with customers. It made it easy to make sure that files stayed secure and only changed by whoever needed to touch them.

I just use it. I'm strictly into command lines, and they just do what I need them to do, and I know how to use them. Everything is just stable and works well. 

It works fine for me, and it does what I need already. It does everything I needed to do, and it has for so many years. The only change that stumped me was the networking in version 9. I preferred the ifconfig way of doing things, but the system changes of it have grown on me. I preferred the ifconfig way because of familiarity. I knew how to manipulate things. I knew how to get things running and stay running and script ways to keep them running and notify me if the thing went wrong. My only gripe has been the networking change and the inability to use ifconfig anymore. I talked to some people, and they did point out that it's good if you're moving from one environment to another environment—like a laptop, but for servers, I don't need that. I just put my config file where I can find it and make the changes that I need.

I've been in this organization for a couple of years, but I've been using Red Hat since version 3. It has been a long time.

The stability has been pretty great. There are some things that we're still working on, but once we solve them, I know they'll remain solved.

Scalability has been great too because when we need more, we just add more, and we're good.

They've been great. I've worked with them a lot lately. They've been a ten out of ten. They're always there for us, and they answer us quickly.

Positive

I've personally used everything from Slackware to OpenBSD, FreeBSD, Red Hat, Fedora, and Ubuntu. I've used everything.

I like the way that everything is predictable with Red Hat Enterprise Linux. You know what you're getting. You know where everything is, and you know that you can find support if you need it. When we're upgrading or if we're adding something, I always know where I could find what I need to find.

I would think that we have seen an ROI. Our licensing has been very fair, but I don't have a lot of visibility into that.

I like my developer account. The free sixteen licenses that they give with the developer account are great because that gives me the ability to keep using it at home instead of trying CentOS or something like that. Once CentOS went away or changed, I had the ability to just make a developer account and spin up my entire lab in Red Hat, which made it better anyway because that's what we use at work, and now I have a one-to-one instead of a clone-to-one.

I've been trying to find a reason to use containers, but I just can't. I know our company uses it a lot, and they love it. They love the ability to shift things around and bring down servers when they want, and all of that, but for my own use cases, I haven't had a reason.

Overall, I'd rate Red Hat Enterprise Linux a ten out of ten. Everything is great.

We use Red Hat Enterprise Linux as an infrastructure support operating system across both x86 and s390 platforms. Specifically, we are running it on x86 Intel and Linux s390 mainframe on Zynq.

Red Hat Enterprise Linux is a stable operating system. We recently upgraded the majority of our systems from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. We were able to automate most of the upgrade process and did not encounter any major issues. As a result, we were able to bring our systems up to date quickly and easily. This is a major advantage of using Red Hat Enterprise Linux.

From an automation standpoint, we have been able to automate some of our patching workflows. This has definitely saved us time and money.

From a security and compliance standpoint, it is easy to maintain compliance. This is mostly accomplished by patching Red Hat Enterprise Linux on a frequent basis. The availability of security patches is also quick, which allows us to keep up with our client requirements quickly. Red Hat usually does a good job of making fixes available in a timely fashion, so we can remediate high-priority issues when they arise.

From a containerization standpoint, Docker and Podman now give us the ability to move workloads and structures around with little effort. It is very flexible and consistent, and the results also provide us with a stepping stone as we move towards an orchestration platform like OpenShift. Our ability to run Podman on servers and then migrate those Podman deployments to OpenShift is very beneficial.

The most valuable features are ease of support and the ability to run a read-only course on the operating system.

Red Hat Enterprise Linux is easy to maintain. We currently use Red Hat Enterprise Linux 7 with Docker for containerization. With Red Hat Enterprise Linux 8, we are moving to Podman, which is a native container runtime that is part of the operating system. 

I suggest that Red Hat move to a continuous delivery model instead of major releases. I know that this is a trend for many middleware products. We do not have a major release network. We only have monthly or quarterly roll-on releases on our continuous delivery model, which reduces the impact of a major version. This would probably be the easiest change to make.

The technical support has room for improvement.

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

Red Hat Enterprise Linux is stable.

Since we run a number of hypervisors for all of our real systems, I believe that a lot of the scalability comes from a level higher than the operating system. However, Red Hat Enterprise Linux can accommodate these tools.

Red Hat support could be improved, and they should have a better relationship with IBM and VMware. This is because a lot of what we do involves working with IBM, both from a hardware standpoint and from a hypervisor standpoint. We have a long history with IBM, and we are now starting to work more with Red Hat on OpenShift private cloud solutions and other tooling. However, Red Hat and IBM are not on the same page. They are still very different companies, and they don't always know what the other one is doing. This can lead to contradictory information, inaccurate information, and frustration for customers. I think there is a relationship between Red Hat and IBM that could be improved. If Red Hat and IBM could work together more effectively, it would put customers at ease and make them more confident that they could get the work done. It would also help IBM and Red Hat to better understand each other's products and services, which would lead to better customer support.

For example, we recently had an incident that started as a severity two on the scaling. A number of our account representatives called and emailed us, saying, "Hey, we wanted to let you know that you have an open case. We need some help with this." The incident was not a production outage, but it was preventing us from doing something, so there was an indirect production impact. After about ninety minutes of back-and-forth communication, we were told, "Okay, go ahead and bump it up to severity one. That should get traction." We did not hear from anyone for four hours. This does not happen every time, but in this case, it needed to be dealt with well before four hours. It made things more difficult than they needed to be. Sometimes the support is an eight out of ten, and sometimes it is a four.

The end result was still good because they acknowledged what happened and got everyone together to resolve it but it was not done in an efficient way.

Neutral

The initial setup of Red Hat Enterprise Linux is very straightforward. It is not much different from any other Linux operating system. Most of the things we need to consider when deploying Linux are relatively standard. Therefore, Red Hat Enterprise Linux is easy to deploy and maintain. If we know how to administer Linux operationally, then Red Hat Enterprise Linux should be easy to deploy.

I do not know enough to give a comprehensive answer, but other operating systems are in use at my company because they have more favorable licensing terms. This is a major factor in why we do not use Red Hat Enterprise Linux everywhere.

We evaluated SUSE Linux Enterprise and a few others. Depending on the computing platform, it is sometimes better and sometimes not. For some of our environments that are running on s390, SUSE Linux Enterprise gives us a better price point. However, for some of our other environments, such as x86 on VMware, it is more valuable. It is a better financial move for us in those cases. Therefore, the value of SUSE Linux Enterprise changes depending on the computing architecture.

I give Red Hat Enterprise Linux a ten out of ten.

We have a requirement to have a Linux operating system.

I'm not sure how our developers are building their images. I believe they use some desk start products.

We use SUSE Linux Enterprise for Linux on the mainframe. In a particular enclave, we have some government contracts where we use Red Hat Enterprise Linux for a number of reasons, including licensing for hosts. These hosts are hosted with OpenShift. We use Red Hat Enterprise Linux for all our Bastion hosts and OLS for our other hosts.

The Red Hat knowledge base is generally an eight or nine out of ten, but it can be difficult to get the information we need. The initial level of support is a six or seven, but it improves as we escalate the issue.

The use case in my very early years was for dedicated servers for doing web applications.

We almost exclusively use Red Hat. The benefits boil down to the support. There is no problem getting support. Whenever we have an issue that we cannot solve, which does not happen often, we have somebody who is there either virtually or physically.

We use Red Hat Enterprise Linux on-prem and on the cloud in a hybrid environment. We probably also have edge devices. I am not completely sure about that one. Having it in a hybrid cloud deployment has been no different than having it on-prem. Running it on-prem is just as good as running it on the cloud for us. It simply works.

I appreciate the dashboards that are available online. There has been a lot of feedback on the CVEs. The most recent one that came was probably related to Zutil. Red Hat made an announcement very quickly saying that if you are using only Red Hat features, you do not have to worry about it. It does not run on their operating system. Unless you are custom compiling, it does not work on their system. I greatly appreciate little things like that because they save us a lot of time. If Red Hat is simply saying that it is not a part of their repo, I do not have to look for it.

We use Red Hat Insights but not company-wide. It is one of those things that simply saves you time. I do not want to have myself or anyone on my team go out and check various things. That is the whole purpose of using Red Hat Satellite. The whole purpose of all different dashboards and these websites is to use what you have. Let it report out what you have and not continue to write scripts just to check things.

Their support is valuable. Whenever I had a problem, I could get on a phone call with somebody. I did not have to go to some random forum or send an email and wait forever. I could call somebody.

It does have a workstation option, but you rarely hear anything about it. I would love to see the workstation replace Windows. That is a stretch goal, but it is possible.

I have been using Red Hat Enterprise Linux since version 4. It has been a while.

It is stable as long as you do not do something stupid.

Red Hat specifically works hard to make it difficult to not be able to scale it into anything. The only thing that I do not see it being capable of, officially at least, are the IoT devices. Technically, it is possible to get it on those devices, but that is not something Red Hat is focusing on right now. From a scalability standpoint, it comes down to what makes a reasonable profit and what is a good return on investment while choosing how to scale and where to scale. Red Hat is doing it right so far.

Prior to a few months ago, the support that we got from a TAM point of view was next to none. Now that I understand the scenario a little bit more, it was not because Red Hat was not doing its job or did not want to do more support. It was because of how the contracts aligned, and more importantly, who in our organization was handling those contracts. We had a recent change in our organization in terms of who is running what and who is handling what. When that change happened, the doors really burst open. Now that we have a different person he is working with, we are getting incredible support from our TAM. He is in communication with us on a very regular basis. While I have been here at Red Hat Summit, we have gone out to have meetings twice. I cannot speak highly enough. I would rate their support a ten out of ten.

Positive

My current organization has pretty much always used Red Hat, specifically Red Hat Enterprise Linux. There are all sorts of flavors of Unix in our environment. Almost all of them are there because they are managed network devices.

We wanted to stay close to Red Hat Enterprise Linux simply because of the mentality of the business. We have got some people who have been around for 20 years. Things such as switching from YUM update to APT update are easy. People can usually change from one to another pretty quickly, but some of the other commands that you are used to running in Red Hat Enterprise Linux are slightly different for different versions of Unix. It did not make sense.

I have used a lot of different variants through the years. I could be running Raspberry Pi, or I could be using Ubuntu to do a job but not for the production environment. I do not waste my time anymore. I know what works and where support is.

Our setup is a bit of a hybrid. We are streamlining a lot of things and trying to redesign how we are doing things. In terms of the cloud, we are 100% TerraForm. We are building out infrastructure as a code and TerraForm pipelines. On-prem, we have a Jenkins job that runs some TerraForm, which then runs some Ansible and then some Puppet. There is some cleaning up needed there.

Currently, we use all three major cloud providers: Azure, Google Cloud, and AWS. Each has its purpose.

The initial experience of deploying it at the current company was terrible, but it was not a Red Hat issue. It was an internalized issue that took a little bit of time to work out. After that, it was not a problem.

We implement it on our own.

I have not run into a single person who knows about Red Hat Enterprise Linux and is not being helpful. You can get talking with somebody at Red Hat Summit about what you are doing on Red Hat Enterprise Linux, and they will be like, "I did that a couple of days ago. Did you run into this problem too?" There is a community. I am sure there are communities for other variants, but my return on investment is simply community and support. I cannot speak highly enough of these two.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would say, "Good Luck!" We looked at a lot of different options to potentially leave Red Hat simply because of the cost. We tried out CentOS. We tried out Rocky. There were even talks about trying out Ubuntu, but there was the hassle of changing all of our mentality and code to work with different systems. It just did not make sense. CentOS worked almost side by side with Red Hat, but certain things that we have specialized with Red Hat were not working on CentOS for some reason.

We chose not to use CentOS because we had a misunderstanding of what AppStream was in terms of end-of-life for CentOS. Rocky was ruled out pretty quickly simply because of a lack of understanding in terms of:

• Where does Rocky come from?
• How reliable is it?
• Where is the support?
  

Red Hat's support model trumps a lot of those other ideas. I tell people that even if they are working in a home lab environment, get a developer license and get a developer account with Red Hat. Use Red Hat because more and more businesses I work with simply use Red Hat. It is great to have Fedora on your laptop as a workstation. It is great to have CentOS as a workstation. That is because those are still a part of Red Hat. You can transition and use Red Hat for a company. I have not been a fan of Ubuntu and some of the other variants because of how easy it is for people to make changes to operating systems that are not fully backed or tested. In my opinion, you do not want to put production on it.

Red Hat Enterprise Linux has not enabled us to centralize development. We are moving towards centralized development, but there are still so many different teams, so centralized development is not yet there.

We are partially using Red Hat Enterprise Linux for containerization projects. Within the next year, I hope to bring OpenShift in and replace AKS. I do not have a use case for the portability of applications and containers built on Red Hat Enterprise Linux. Based on what I have seen here at Red Hat Summit, I have a lot of ideas spinning around in my head to make it happen, but I do not yet have anything around containerization.

Red Hat Insights provides vulnerability alerts and targeted guidance, but we are currently not using that side of it. It helps in my limited sandbox environment, but of course, my sandbox is built up and torn down like crazy. It is valuable, but we do not have a great use case yet.

I would rate Red Hat Enterprise Linux a ten out of ten. I have been working with Unix systems for a while now. The first Unix system I touched was in 1992. There were so many variants that were striving to become well-known. You would hear all of these weird names. There were all of these weird animals and all of these different logos through the years. Even before 1992, there were a lot. As things progressed, you quickly saw different ones die out. I do not remember when I truly got onboarded with Red Hat. I know I started with version 4. It is one of those companies when you are looking for a name that sticks around and about which you do not have to question if they are going to be around for a while. You do not have to question that with Red Hat. You do not have to question that with Red Hat Enterprise Linux, whereas a lot of other variants do not even exist anymore, or they exist, but they have not been maintained longer than some people have been alive.

My organization has different departments. In my department, we mostly work with containerization. I am using Red Hat Enterprise Linux as a part of OpenShift. I use the basic package and base image of Red Hat Enterprise Linux.

For scale-up in our platform, we use CoreOS as the master, and for the workers, we use the Red Hat Enterprise Linux service. From OpenShift version 4.10 onwards, we cannot use Red Hat Enterprise Linux 7 worker nodes. We were using Red Hat Enterprise Linux 7 worker nodes, so we upgraded to Red Hat Enterprise Linux 8. 

For OpenShift, there are some recommendations from Red Hat in terms of what needs to be used for the control plane and what needs to be used for the worker nodes. When you are using CoreOS and Red Hat Enterprise Linux worker nodes, there are some difficulties in managing them. For example, when you upgrade OpenShift, you need to upgrade two times. The control plane is upgraded separately because it uses CoreOS. The control plane has a lot of certificate updates that will in turn be updated on the worker nodes, so you have one restart of all worker nodes, and then when you need to upgrade your worker nodes, there will be one more restart. 

Overall, you have two reboots in your production environment, which is an issue, but it is related to your choice of product in your environment. We have this issue because we opted to use Red Hat Enterprise Linux 7 or Red Hat Enterprise Linux 8 worker machines, whereas Red Hat recommends using CoreOS because it is pretty fast in terms of rebooting and functionality. When you upgrade the control plane, that itself will update the worker nodes, so you are done in one shot. When you need to upgrade your Red Hat Enterprise Linux machines, you need to use the Ansible Playbook. You can then upgrade to Red Hat Enterprise Linux 7, 8, or any other version. Regardless of the versions, you can upgrade the operating system and the OpenShift version. For this purpose and for some ad-hoc activities, we are using Ansible Playbooks.

For us, its security, management, stability, and hardening are most valuable. All of these features are better in Red Hat Enterprise Linux as compared to Microsoft Windows.

Red Hat Enterprise Linux is very good in terms of risk assessment. It is also good for maintaining compliance. It is better than Microsoft Windows.

From the administration perspective, I do not have any issues with Red Hat Enterprise Linux. For me, it is more convenient than Microsoft Windows.

My organization has been using Red Hat Enterprise Linux for a long time. They have been using it before I joined the organization.

It is pretty good in terms of stability. It is a stable product. I would rate it a nine out of ten in terms of stability because sometimes the packages can have bugs.

Its scalability is good. I would rate it a nine out of ten in terms of scalability.

We never encountered any issues while using OpenShift.

I have mostly been working with Red Hat Enterprise Linux. 

I have been involved in the deployment of OpenShift. It is pretty straightforward. We just need to get the licensing, and we just need to create a pool for our containers session in Red Hat Satellite. We can do the configuration from there. It does not take long because we are adding the nodes to OpenShift. During the scale-up process, we only need to subscribe to the nodes with the Red Hat subscription. It does not take much time. If we have a good spec, the scale-up would not take much time. It would take less than twenty minutes. It is pretty fast.

In terms of maintenance, when we have the bug report, we need to do the security assessments. Over time, there might be some bugs related to some packages. At that time, if it is critical, we will be scheduling a maintenance activity on our platform. 

Red Hat provides high availability from the application perspective. You get high availability when you are using OpenShift, so when you are doing a maintenance activity on the OpenShift side, there would not be any downtime. The high availability is very good. For the end-users, there would not be any application outages if you configure your application with proper replicas. They would not even realize that there is a maintenance activity happening to the underlying workers.

It was implemented in-house.

We did not evaluate other solutions. Red Hat Enterprise Linux is the choice of most of the companies.

If you want to integrate with OpenShift or build an OpenShift cluster with the master Red Hat Enterprise Linux and worker Red Hat Enterprise Linux, you can do that, but you need to plan your upgrade or maintenance activities. It would be better if you choose CoreOS for both. CoreOS would be a better choice in terms of maintenance activities or upgrade activities in the future. If you cannot afford that, you can go with the Red Hat Enterprise Linux operating system, but you need to do two upgrades. You first need to upgrade the control plane and then you need to separately update your worker nodes. That is the only thing you need to keep in mind.

I would rate Red Hat Enterprise Linux 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.

We deployed Red Hat Enterprise Linux on-prem and in the cloud as a fallback.

We are a private cloud provider and we host Linux ourselves because they are tough to manage.

We offer our customers the option to host their Red Hat Enterprise Linux on Azure or on our private cloud.

Red Hat Enterprise Linux's built-in security features help simplify risk reduction. Red Hat offers a subscription service that provides critical security updates within 24 hours. The service also includes an excellent database of known security vulnerabilities. If a CVE identifier is known for a vulnerability, it can be entered into the web interface. The web interface will then indicate whether Red Hat Enterprise Linux is affected by the vulnerability and what steps need to be taken to fix it. The fix will be included in the next security update. This is a valuable security feature that helps organizations to stay up-to-date on security patches and mitigate risk.

The portability of applications and containers built on Red Hat Enterprise Linux is beneficial for keeping our organization agile. Red Hat Enterprise Linux 8 and 9 include Podman, a newer software similar to Docker. Podman was built to address the problems that Docker had with creating and running containers, and it also includes the support of Red Hat. There is a good synergy between Red Hat and Podman.

Red Hat Enterprise Linux has helped improve our organization. We provide a service to our clients, which they pay for each month. This service includes our support. Red Hat Enterprise Linux is a stable operating system, so we do not have to provide much support. When we do need to provide support, it is usually for an application, not for the operating system.

I can build with confidence and ensure availability across physical and virtual cloud infrastructures using Red Hat Enterprise Linux. I have been using Red Hat Enterprise Linux on-premises since 2008 without any problems. It is easy to automate. Virtualization is always present, so I work with virtual machines. Red Hat Enterprise Linux is very easy to deploy on a virtual machine. We can create a virtual machine, and if we are working with VMware, we can create a template to use for new systems. There is no need for a classic installation.

The updates are the most valuable feature. In the past, we had 800 or 900 Linux systems with Red Hat, and all of the systems were updated every night. In the 14 years, we have only had ten issues with the updates.

Red Hat Enterprise Linux has a good configuration.

Red Hat Enterprise Linux is secure but the security always has room for improvement.

Scaling can be complicated and has room for improvement.

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

Red Hat Enterprise Linux is stable.

I give the stability an eight out of ten.

I give Red Hat Enterprise Linux a seven out of ten. 

Updating Red Hat Enterprise Linux from version 8 to 9 is a complex and time-consuming process. It is often easier to install a new server with Red Hat Enterprise Linux nine and migrate our data and applications. However, if we only need to resize the CPU or memory of our existing server, we can do so using the hypervisor without having to reboot.

Red Hat support is fast, and they are capable of answering 90 percent of our questions.

Positive

We previously used Debian, Ubuntu, and SUSE Linux. In our case, if we wanted a conservative Linux system that did not have the newest version, these were perfect systems. However, if we wanted to install them on our laptops or on our clients, they were the wrong solution. We switched to Red Hat Enterprise Linux for the Red Hat support. Debian also offers its own support. Ubuntu does not offer direct support, so we were required to order it through another company. SUSE had other problems that we did not want to deal with. Red Hat Enterprise Linux support has been very helpful to our back-end admins.

The initial setup is complicated, but with Red Hat Enterprise Linux nine, there is a graphical web interface where we can create a new image every week. We have created a golden template that enables us to update the image every month and upload it to both our private and public clouds for usage. 

The deployment time depends on whether we have a template or not. With a template, deployment can take between five and ten minutes. If we have to install the software, the time it takes depends on our internet bandwidth. Ten gigabits of bandwidth can take around 15 minutes to install.

The implementation was completed in-house.

As a provider, we must follow a different licensing model. We charge €2,000 per system for three years. Each month, we provide Red Hat with a number of new and old systems. Red Hat then invoices us based on the number of systems in use that month. This only applies to our cloud customers.

I give Red Hat Enterprise Linux a ten out of ten. Red Hat Enterprise Linux is the best thing I have.

We always install a minimized Red Hat Enterprise Linux system for our customers. If they require more features, we provide them as requested.

Red Hat Enterprise Linux is the most perfect OS I have ever worked with. It is nice knowing when we have to use the OS and when we don't.

All Linux solutions are open source, but Red Hat Enterprise Linux is a commercial product that includes support and frequent updates. Red Hat Enterprise Linux can be downloaded for free, but it is not recommended to use it without a subscription, as it will not receive security updates or bug fixes. Red Hat reinvests a portion of the subscription revenue back into open-source projects, making it possible for other organizations to use these technologies for free.

Maintenance requirements depend on our needs. If we only want to have a server and install updates every night, no additional maintenance is required. Red Hat Enterprise Linux does not require any special support. However, if we want to ensure that the system time is always correct, that all updates are installed within a month, and that the system reboots after updates are installed, we will need to perform some additional maintenance tasks. These tasks can be automated to ensure that our system is always running smoothly. We currently have three people for the maintenance. We currently have 900 systems.

I recommend evaluating multiple Linux solutions and conducting a proof of concept because, although Red Hat Enterprise Linux is a great operating system, it may not be the best choice for every organization. I do not recommend using Red Hat Enterprise Linux on a new laptop because the versions included in Red Hat Enterprise Linux are typically two to four years old. This is because Red Hat Enterprise Linux is designed to be a stable OS, and newer versions may not have been fully tested and may have issues. If we have a server or software that is certified for Red Hat, then I would always recommend using Red Hat Enterprise Linux.