Red Hat Enterprise Linux (RHEL) Reviews

We are doing image building. Our team focuses on the image of the platform and presenting it in a secure way for everybody to consume.

My organization had already been using it before I started, so I am not sure what benefits they got from Red Hat Enterprise Linux. They were already a Red Hat shop when I started.

We do not utilize Red Hat Insights as much as we would like, but we know that it is there. It provides the data, and we can act on that data, but we do not use Red Hat Insights the way we should. However, it does tell us when things are critical and need to be patched. If something is on there and it is critical, we can at least see that it is patched. The alerts and targeted guidance from Red Hat Insights have not affected our uptime so far.

It is open source. Most of the features are already there for you. They make solutions for challenges that we do not even think about sometimes, but we may consume them later.

I have not put in many feature requests. They have mainly been around small things such as monitoring with Ceph. I cannot remember the name, but monitoring was needed for a specific function. It was a pretty important function, but there was no monitoring set up. It took some extra effort. That was the only feature I asked for. I asked them if they could set up a monitor to make sure that the system was healthy or working correctly.

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

Its stability is fine. I have not seen too many issues with stability.

Its scalability is great. We can scale up or down.

I do not have any issues with the customer service or tech support. It is good. I would rate them a ten out of ten because they can usually resolve anything.

Positive

The deployment of Red Hat Enterprise Linux is pretty simple. There are not so many issues.

We are using it on the cloud and on-prem. We are trying to get to Azure. We are not using it in a hybrid cloud environment. I know we are setting up OpenShift in Azure and on-prem.

We have been using TerraForm to create images and Ansible to make sure everything is fine. We have some things on Azure, but we are trying to make it easier for people to consume Azure. We are trying to get that automation together so that it is a lot easier if anybody wants to spin anything up in Azure. They have a container to use that is secure. All of our business tools are on it.

We just use Red Hat. We do not use any integrator or consultant.

Our team does not use a lot of containerization, but we probably will be doing that soon with VMware changes. We are trying to get more of the monolithic stuff down to containerized workloads. We will hopefully see some return on investment after we get our VMware stuff out and get more things containerized. We are working with the OpenShift team, and we will be able to see some ROI.

That has been mostly handled by Red Hat. As we are a Red Hat shop, we have a lot of people around that already.

We do not use the security features of Red Hat Enterprise Linux. There are so many scanners out there. We do not use what is on Red Hat Enterprise Linux, but we do set it up. They are at least available to consume. We do not use them because we have so many security compliance tools. As a bank, we have to use those for auditing and other things like that.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would say to get something that is close to Red Hat. Red Hat is killing a lot of the downstream stuff. All my Linux is Rocky Linux because it is based on Red Hat Enterprise Linux. I would suggest getting something that is close to Red Hat Enterprise Linux so that if they or their company does not want to go for Red Hat, they would still have the same tooling and the same infrastructure.

I would rate Red Hat Enterprise Linux a ten out of ten. I have not seen a lot of issues with Red Hat Enterprise Linux. I am overall satisfied with it.

We are moving toward a microservice architecture and using OCP4 as a platform. We run most of our APIs in OCP ports, so the base image is always Linux. It's a Linux image, and we add our own dependencies. We have a private and public cloud, so it's a hybrid cloud system, and we rely on on-premise data centers as well as the cloud. 

Red Hat Enterprise Linux supports our hybrid cloud strategy because we can have Red Hat Enterprise Linux on the public and private cloud, improving compatibility. 

If the compatibility is high, it's easier to move and migrate. If I have some components on the private cloud on Red Hat Enterprise Linux and components on the public cloud. 

Red Hat Enterprise Linux stands out for its stability and support, which are critical for enterprise applications in the finance sector. We don't want any downtime, so we need fast support and quick issue resolution. 

The main security feature is the regular patches and updates. When we do a security scan, there should be patches readily available. Security is essential in finance, and Red Hat Enterprise Linux helps us build a solid IT infrastructure foundation. 

I've used the Red Hat Enterprise Linux Web Console to configure the products. It's a nice tool with an intuitive interface that gives you a better picture of what you're configuring. It's helpful. 

Red Hat Enterprise Linux should be available in a free version that developers could try on their own machines before deciding to implement the enterprise edition. It would be nice to have a community version available with all the features so developers can become more familiar with Red Hat Enterprise Linux. 

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

We haven't experienced any major outages or downtime. Most of our issues are quickly resolved. We don't typically upgrade to the latest and greatest because we want to ensure stability, and we have a lot of the components on the old system. We wait for a while to upgrade so we can see the most widely used and most stable version. 

I rate Red Hat support eight out of 10. 

Positive

We had Satellite and Red Hat Enterprise Linux from the beginning, but we also use other flavors like Amazon Linux. 

I rate Red Hat Enterprise Linux nine out of 10. 

As a whole, our organization is using it on Bare Metal on-prem and the private cloud, and then also in more than one public cloud environment. We probably have all three cloud providers. We definitely have Azure and Google Cloud. The environment that I support has about 40 apps in one cloud or another, but the organization as a whole definitely has hundreds of apps in Google Cloud or Azure. They're predominantly in Azure. The Google Cloud adoption is pretty recent compared to our Azure utilization.

I'm supporting a capital markets environment. A substantial portion of my environment is still Bare Metal at Colos. I'm sure on the application side, there's plenty of JBoss in our environment. There have been recent conversations around OpenShift on-prem that I'm working on, and our enterprise cloud teams are looking at or are using ARO in the cloud. In the next year, our use of the Ansible Platform will go from zero to full throttle as quickly as we can make that happen. We found the event-driven Ansible very interesting.

They've helped us work on employing technologies suitable to our various use cases. We're pretty slow adapters of containers, but that seems to be changing fairly quickly at the moment. That certainly gives us portability for workloads. They helped us with some aspects there, and they've helped us with a lot of automation conversation at the summit this week as well around Ansible.

When it comes to resilience in terms of disaster recovery, the operating system is robust. If it fails, it's probably an app issue. The majority of work in any of our DR scenarios is dependent on whether we have got cold standby or hot standby. If it's hot, the data replication is already there, and things are already spinning. Maybe it's on or you turn it on. Other times, you may have to start up something. Nearly all of those things are application architecture decisions as opposed to dependencies or things from an OS perspective, but in terms of the ecosystem for managing our Linux environment, using Satellite and so on has been very good.

I prefer it to Windows because of the level of configuration, level of control, and the ability to see the performance of processes on a given system. I prefer the control over logging and the ability that logging gives you to investigate a problem.

Its community is also valuable. It's open source, and Red Hat-supported streams are also valuable.

The level of communication we've got with them is fantastic. 

The integration with the apps and support could be better.

A colleague was talking about having some recommendations for the Ansible Cloud on the console and having some way of identifying your dev or prod path and whether you've got read or execute access to a playbook. There were different things like that, and they made a lot of sense, especially if you're in a dev or prod environment because mistakenly running something in prod would be a huge issue. There could be something that Red Hat configures, or there could be a text field where organizations can add labels to a part of the console to distinguish that for themselves. Those would be things that would be useful. I can't imagine it's hard to implement but being able to know which environment you're in matters a ton.

As a part of my professional career, I've been using it since 2004. I joined my current organization in 2018. It has been almost five years since I've been working with Red Hat Enterprise Linux in the security environment of our organization.

It's stable. We rarely have our systems crashing.

It's pretty easy and getting easier. It's not an OS issue. In terms of scalability, even while running our trading apps, we don't run into limitations related to the OS. Our limitations are more hardware-defined, and even then, we're running Red Hat Enterprise Linux on servers with eighty cores and almost a terabyte of RAM, and the OS doesn't have any issues.

Their knowledge base is great. There are lots of times when we don't even have to open a support case because we find what we're looking for.

I've spent a lot of time with the Red Hat account team over the past nine months. They've helped me understand products. They've helped develop the skills of my team. They've helped us with technology conversations with other parts of my organization. They've been hugely supportive of the technology conversation we're having with other parts of the bank.

They've been over and above the expectations in most cases. I'd rate them a ten out of ten. I don't know if it could be better. It has been extremely good. They've been extremely helpful in reaching out and figuring out what they can contribute. The account manager that they have working with us is a former colleague, so it's a really smart decision because we have a very good relationship with the guy. He knows our environment. It has been extremely positive.

It's a growing relationship with Red Hat. We have been using Red Hat Enterprise Linux for a very long time, and I don't know if we can even compare it to the other OS vendors, but having the account team working with us with that level of experience with our environment helps them work with us. It helps us accomplish what we're trying to do. It has been a very good partnership.

Positive

We get our licenses directly through Red Hat.

We haven't used the image builder tool or insights, but it's something that we might explore in the coming months. 

I'd rate it a ten out of ten. It's very customizable and very supportive. It never seems to crash. There could be better integration with apps, but from an OS perspective, it's excellent.

We run various application servers. We have application servers for Java and Python. We also run Postgres and different applications. We have Kubernetes, Docker, Docker Swarm, etc. We have a wide variety. 

We weren't trying to solve a particular problem by implementing Red Hat Enterprise Linux. We've used Red Hat Enterprise Linux for so long. We used to modify the Kernel in the early versions of Red Hat, but that's not needed anymore. We are currently using versions 7, 8, and 9. 

Red Hat Enterprise Linux has enabled us to centralize development in our hybrid cloud environment because the containers can be migrated from Red Hat Enterprise Linux to AWS. It's not an issue. There is also a Red Hat-supported programming tool called Skupper, which is a layer seven service. It's an open source product. It's supported by Red Hat, so we could use that to migrate our containers back and forth on the cloud and on-prem, which is very much needed.

Red Hat is pretty good at containing risks. We have a firewall, but we also use iptables and SELinux. SELinux has proved to be very valuable. We have certain tools where when somebody tries to break SELinux, we immediately get alerts.

We don't have a problem with compliance. We also use Red Hat Satellite. Our Red Hat Satellite server is helpful in terms of meeting compliance requirements.

We're able to modify and migrate containers and redeploy containers very easily. We do that on the Red Hat platform. We do it with other tools such as VMware. Red Hat API works very well with other vendors, so that's definitely a plus. In terms of changes, for instance, if we want to connect to ServiceNow to create a ticket in Ansible, we're able to do that without any problems whatsoever. We can create a ticket in ServiceNow. We can remediate it, and we can close the ticket on ServiceNow from Ansible. Ansible is a big part of Red Hat.

It's a rock-solid operating system. We don't need anything fancy from the operating system itself. What we need is something that doesn't crash, stays up to date, and provides the security features that we need to keep external players out.

The CVEs that come out for the vulnerabilities are very fast. We try to do patching in different tiers. Our regular patching happens once every ninety days, and then we have special iterations that need to be done, and those are on demand, or if there's a high-security risk and it's absolutely immediate.

The other thing that we like about Red Hat is the support for open source. That for us is a slam dunk.

They should work more on container documentation. The only issue that we have is that Red Hat specifically promotes OpenStack, and we don't use OpenStack. It's good if you're using OpenStack, but if you're not using OpenStack, and you're using Docker or something else, it isn't that good. Having more support for non-OpenStack would be very helpful, but, of course, as part of their business, we don't expect it.

I've been working with Red Hat Enterprise Linux for many years.

It's very stable.

It scales very well. We have about a thousand servers, but we could scale to five thousand servers without a problem.

Their support is good overall. It's better than some of the other vendors. The staff is very friendly. The people I've met hear and discuss issues. We're very much interested in open source, so we use a lot of open source. The engineers have been extremely helpful. 

I'd rate them an eight out of ten. I'm not giving them a ten. Some of it has to do with the time cycle, and some of it has to do with different levels of quality with the support. You could get a junior support person, and obviously, that's going to be a very different experience.

The knowledge base offered by Red Hat is very good.

Positive

Our environment is hybrid. Most of our Red Hat Enterprise Linux is on-prem. For the cloud, AWS is the cloud provider, but we are using a different distro for AWS. We use AWS Linux for that. For on-prem servers, we're strictly using Red Hat Enterprise Linux. For desktops, we use Fedora.

The reason for using AWS Linux is that we only have AWS. If we use multi-cloud, for instance, if we use Azure and AWS clouds together, we would definitely need something other than AWS Linux. AWS Linux is very solid too, and our team likes it. We can download the AWS Linux version for on-premises too. I've done that. I tested it, but we're sticking with Red Hat Enterprise Linux.

In the server space, nothing comes close to Red Hat Enterprise Linux. I know that Ubuntu is making a big push, and some people have gone ahead and migrated to Ubuntu, but I think those are going to migrate back. There's just no comparability. They're different. They're like cousins. They're very similar in some ways, but they're very different things. You can install SELinux on Ubuntu, but why bother and why go through the whole configuration? Red Hat Enterprise Linux is more suitable for servers.

We use certain tools from HashiCorp, such as Packer, so deploying it is very simple. We have a script that runs every night, and it creates via the CI, goes up to GitLab, gets whatever it needs, such as parameters, and sends it to Packer. Packer grabs the ISO, and it creates a very specific, customized deployment. It's done with a couple of right clicks. That's it.

We've absolutely seen an ROI. It's in terms of reliability, stability, security, and usability. You name it. The use cases are out there.

The licensing structure is very convoluted. It's very confusing. We have a Satellite server, and we license it through the Satellite server, but if we didn't, we'd have to buy individual Red Hat licenses. That would be a nightmare to maintain in terms of renewing it every year and things like that. 

Overall, I'd rate Red Hat Enterprise Linux a nine out of ten.

We have a private banking client who initially started to use Red Hat Enterprise Linux for approximately 30 nodes. They found that Red Hat Enterprise Linux was the perfect operating system for implementing Ansible automation and managing their infrastructure efficiently. They also deployed Red Hat Ansible Tower for centralized management. Due to the stringent security and compliance requirements in the banking industry, they chose Red Hat Enterprise Linux as their preferred operating system to ensure security and governance across their infrastructure.

In terms of clustering, Red Hat Enterprise Linux provides robustness and scalability compared to non-Red Hat Enterprise Linux operating systems. Clustering is not as straightforward with non-Red Hat Enterprise Linux systems. Red Hat Enterprise Linux's scalability is particularly important for us. We utilize Red Hat Enterprise Linux as the operating system to achieve scalability in our operations.

Moreover, Red Hat Enterprise Linux's strong security posture and its ability to scale applications on emerging technologies across the hybrid cloud is next-generation. I believe that's what people are seeking in Red Hat Enterprise Linux. It is built with a strong focus on security, ensuring effective governance and managing security aspects well. We have high hopes that Red Hat will continue to invest more efforts in enhancing security. When it comes to container-based applications and microservices, Red Hat Enterprise Linux plays a crucial role in the hybrid cloud environment.

One challenge we've faced is with databases. Configuring and implementing DBs is much easier in non-Red Hat Enterprise Linux systems, especially in Microsoft. However, as a partner, we faced some challenges with Red Hat Enterprise Linux, particularly when it comes to enterprise applications, especially on the IBM side since it's an IBM core company. There are still several IBM products that need to mature on Red Hat Enterprise Linux. Additionally, we require more comprehensive documentation. We face difficulties with the limited availability of documentation for Red Hat Enterprise Linux. It's a different community compared to the Microsoft market, so we need the right documentation to encourage end users to use Red Hat Enterprise Linux.

We've been using Red Hat Enterprise Linux for the past seven years. As a business partner, we use the application deployed for our clients, providing consulting services. The clients run their workloads on both Red Hat Enterprise Linux and non-Red Hat Enterprise Linux systems. They have two options for cloud providers, hybrid deployments on IBM Cloud and AWS.

The benefit of using a hybrid approach is often discussed when it comes to migrating workloads to the cloud. Due to the OpenShift community, Red Hat Enterprise Linux has become the preferred operating system as it provides stability and frequent patches and fixes. Maintaining the total cost of ownership is also more manageable on the cloud.

It's excellent; in fact, it's the most stable. The presence of kernels is the key factor contributing to this stability. When it comes to security, scalability, and robustness, Red Hat Enterprise Linux (RHEL) excels in all aspects. That's why we rely on this operating system. Personally, during my time as a technical assistant from 2015 to 2016, I installed a couple of IBM applications. I found that everything ran smoothly on Red Hat Enterprise Linux without any failures.

So the stability in Red Hat Enterprise Linux is remarkably good.

The scalability is nice. Red Hat Enterprise Linux doesn't encounter any issues as a supporting core. It can scale effortlessly.

I have personally used Solaris. However, we eventually switched from those operating systems, but Red Hat Enterprise Linux has been there since version 4.2, a long time ago. I have worked with versions 7 and 9, and I believe the latest one is version 11, although I'm not certain. I have been immersed in technology for the past couple of years.

One of the most important factors is the community. The Red Hat community is different from others, and it is more active and responsive. If you have Red Hat Enterprise Linux and you want to move your production environment from development or testing, it is easy to switch by simply managing the licensing and purchasing the system. You don't need to make extensive changes at the underlying system level. Your system is ready, and you can deploy it in the production environment. It's up and running. If you want to mitigate risks and ensure security in your production environment, you can simply subscribe to RHEL and use it. On the other hand, migrating from other operating systems can be quite cumbersome and challenging. As a client and partner, I always recommend starting with Red Hat Enterprise Linux in the development and testing environments before moving to production. It makes the journey to production much easier.

Regarding centralization, we have a combination of on-premises and cloud environments where development activities take place. Currently, I don't see a specific use case for centralized development and operations, but Red Hat Enterprise Linux is being widely used both in on-premises and cloud setups. As for hybrid deployments, I haven't personally come across many instances of it. There may be a few customers who are utilizing it but not with us thus far.

Red Hat Enterprise Linux's built-in security features in terms of ensuring application and container portability are not an easy task. Although it's not my personal experience, I've observed that in the industry, there is a lot of discussion about moving toward container-based applications. However, only a small number of clients, especially those in highly regulated industries like banking, government, and oil and gas, have actually embraced containerization. They are facing significant challenges when it comes to adopting container-based applications. Many of them still rely on legacy systems running on-premises, such as mainframes.

I have seen an ROI. The most important determinant is the security aspect. Because you rely on the security of Red Hat Enterprise Linux, that's something you are paying for.

When it comes to Red Hat Enterprise Linux pricing, I have a case to share. We recently sold Red Hat Enterprise Linux OS to one of our clients. Before that, I had another client who had concerns about the OS licensing and Red Hat Enterprise Linux's pricing model. The licensing model needs to be more flexible and dynamic because the cost of a single operating system license is relatively high. I'm not suggesting a reduction in cost but rather the introduction of a different model that allows clients to choose scalable options. For example, if a client has licenses for a few operating systems and wants to expand to 50, 100, or even 200, there should be a proposal that offers them flexibility. 

Currently, most clients tend to opt for a limited number of licenses and rely on the community for additional usage, which results in revenue leakage. Red Hat should consider adopting a more aggressive open license policy that encourages higher volume licensing with clients.

When you use Red Hat Enterprise Linux in production, it's worthwhile considering the cost. But even for non-production environments, the client will definitely calculate the expenses since it's a massive implementation for large clients with an operating system. You will open your laptop, and you just need an OS. So my suggestion is for Red Hat to create a business model that also targets the user level and desktop level, where Microsoft is widely used. Considering this eventuality and how many people are switching or still using Red Hat Enterprise Linux, we, as a partner, mandate that all our Red Hat team members use Red Hat Enterprise Linux. We don't allow them to use any Microsoft operating system or other operating systems. When engineers join the company and work in the Red Hat pillar, they have to use Red Hat Enterprise Linux.

Red Hat Enterprise Linux's built-in security features, in terms of simplifying risk reduction and maintaining compliance both maintaining compliance and security, are essential aspects. Compliance requirements vary across different industries, such as banking, with each industry having its specific rules. However, security is a common concern that applies universally. Therefore, we need to address both areas.

Red Hat Enterprise Linux provides various logs and event triggers that assist in monitoring the operating system's security. Since the operating system sits as the layer between the hardware and the application, it plays a crucial role in safeguarding against security breaches and penetration attacks. A secure application relies on robust application security, followed by a well-protected OS. By ensuring the OS's security, we can establish a strong foundation for the entire ecosystem. If the OS is secure, we can confidently state that the application is at least 80% secure.

Overall, I would rate the product an eight out of ten. 

I use Red Hat to run applications like Apache, MySQL databases, etc. It is suitable for data storage and firewall. I can also measure performance with the SAR tools and do all I need with the Linux stack. I run several server farms, community applications, and more. Multiple teams use it. We have a hybrid setup, but we try to keep the use cases separate for each, so they're not transiting that much.

RHEL has made it easier to create, view, and update pools. We spin up a new one when necessary. We can quickly bring one down and move the traffic over, and it's a lot simpler to keep, update, and manage our application.

The solution has helped us achieve security standard certifications. Having the reporting on Ansible and other management components helps. We have a dashboard we can use and a blueprint to assist with the container. RHEL's toolkit helps us see which versions are running, so we can keep it lightweight. Also, having a newer base image ensures we have a standard. We always get what we're expecting. 

It helps us centralize development and move DevOps forward. They have a lot of support from multiple providers. I like having that standard. It makes it more straightforward for our developers to do troubleshooting here and there. The pipeline and support from the Red Hat team made a difference.

Red Hat support is pretty good. They're online, so you can look up things once you have support. Their AB integration has improved. It's easy to manage storage for moving, syncing LBM, etc.  

Red Hat excels at built-in security. There are lots of new security features in terms of profiles, email, using satellite, and disabling root login. They've got modules and built-in Ansible features. You can customize how it remediates, and Ansible will tell you what's out of compliance as you add rules.

Their container platforms are among the easiest to manage. Once you're done pre-testing, it is easy to migrate after you deploy in a sandbox. They have their inbox IDE and the like. 

I also think it's great that you can use one payment management system if it works correctly. You can see your overall footprint from both sides together on one screen.

I would like Insight to include some features from OpenSCAP, which they offer for compliance services. I played with it a little bit, but haven't gotten the updated setup to get that. It creates excellent documentation.

I have been using RHEL for 10 to 15 years.

RHEL is one of the more stable Linux platforms. 

RHEL is pretty scalable and easily rentable.

I rate RHEL support a nine out of ten. We can do captures to easily show them the issues we're having, and their response times are above average.

Positive

We had some smaller setups with this where we had some room for development, but now we're trying to standardize everything using smaller footprints, and not having to manage more workspace stuff. Now we're pretty much in RHEL and working on that.

RHEL was already there when I joined the organization, so I inherited it. In terms of maintenance, we try to keep it up to date. 

RHEL's price seems to be consistently changing, depending on what you're after. We might need a more extended license to lock in a price if it keeps changing. It would be nicer if it stayed steady within a specific range, but it's negotiable. We try to negotiate, and maybe a more extended contract would be better. 

When comparing to other solutions, you must consider the reporting and security features. It's an expense that we need to pay in terms of compliance. When you talk with your partner companies or potential customers, they need to know that we're on the ball and keeping up.

We have considered other solutions, but we see the added value from Red Hat, and there are many more features, so we must have support. I'd say we didn't do too much evaluation. We liked Red Hat from the get-go because they've got backing from IBM now. Also, they have started their own server- or container-oriented stuff. It helps to consider if we'll ever work with just Red Hat on AWS, given the ease of spinning things up.

I rate Red Hat Enterprise Linux a nine out of ten overall. I don't think RHEL is exactly perfect, but it's a trusted, easy and well-supported solution. They are constantly improving and trying to make it easier. 

I worked with different organizations. So, the use case varies from organization to organization. Right now, some of the teams are using it for applications like BI, and then there are a few others that are using it for Websphere, middleware, etc.

In terms of the version, most of them are on 7.9, but there are a few on 8.2 and 8.4 as well.

It enables us to achieve security compliance. Our security team is quite happy, especially in terms of patching up our servers, etc. It's compliant with our security requirements. With Windows updates, sometimes, there could be errors and the blue screen issue, and it could become hectic for the applications as well. Our security teams struggled a bit to update Windows, but when it comes to Linux, they are quite comfortable because they know that things will go smoothly.

I'm quite new to this organization, but I know that there has been improvement in terms of performance. We're using Red Hat Linux on Power Systems, which is quite different from the Intel platform. So, admins are much happier, and they are using it quite well now. Previously, we were using Windows for our applications, but now, we have made Linux mandatory for being open source and not bound to Windows. Things can be complicated on Windows. Especially when we're installing it, there are a lot of things, such as registries, but Linux is easier for admins. There is DVS as well.

When I worked in the banking sector, the most important part was user administration where you need to keep things under control for a specific user. The auditor usually looks for an agent or something like that, and it has been quite easy to manage things from that perspective. Things are more manageable now than in the past.

Windows operating system is used everywhere. You will find it everywhere, and every user is able to use Windows. If a user is using an operating system from the start, it becomes easier for them to use it when they come to a professional environment. That's an area in which I believe they need to put in extra effort, especially for the students. Currently, for their final projects, most students use Windows, and this is an area where Red Hat needs to put in an effort. They need to give some training to the students so that when they come to the professional environment, they're already used to it. It would then become easier for them to use it in a professional environment.

I'm also using IBM AIX, which supports a tool called Smitty. You just put Smitty, and you can do anything. At the backend, the command will run automatically. It is not exactly like a GUI, but you just give the input and it will give you the output. That is something that Red Hat should work on. That would be an added advantage with Red Hat.

It has been 12 or 13 years.

It is very stable.

We are mostly using VMware and Power Systems. Scalability-wise, they are always the best. We can upgrade to get all the resources on the fly. We never faced any issues. However, if you didn't add the required parameters on your profile on VMware or the Power System, then there is an issue, but that's not related to the OS. That's related to virtualization.

Application-wise, there are multiple teams that are using these systems. We have the database team, the middleware team, the MQ team, etc. There are also system admins. The system admins are the ones who are deploying it, but the owners of the system are different.

We have plans to increase its usage. Two years ago, we had only 60 or 70 servers of Red Hat, but now, we have 400 to 500 servers. Its usage is always increasing. After a year or two, we might end up with about 1000 servers.

We have contacted them a few times. We did ask the support team to get in when the cluster got stuck and let us know what's the issue and what's the solution. Whenever I have asked for support, they have provided the best support. I always count them as the best. We have never faced an issue with them. I would rate them a 10 out of 10.

Positive

We had Windows. The stability was the reason for switching to Red Hat. The stability of Windows varies, but Linux is quite stable now. That was the main part they were looking for.

We are very comfortable with using Linux. We have been using it for 10 to 15 years, and we can't switch to Windows. We can't use Windows even on our laptops. We are not used to using a mouse and GUI. The command prompt is much better for us.

We also use AIX because we have AIX infrastructure, but a few of the applications don't work on AIX, whereas they work with Red Hat Linux. That gives Linux an advantage. So, we use Linux on Power Systems, rather than AIX.

We have been working with different operating systems, and we also know most of the technical requirements, so it is easy for us. Usually, the OS installation takes a maximum of 25 minutes. If you are making extra file systems, such as for Oracle, it takes 10 to 15 minutes extra. A desktop or a single file system doesn't require much time. We already have scripts. We just run the scripts and everything is done by the scripts. Previously, it used to take two or three hours, but now, things have changed, and we're making life easier.

We deploy it ourselves. We don't ask other vendors to deploy it for us. In terms of maintenance, we have already been updating our maintenance contracts, especially the support contract. There are some old systems running in our environment, and we are in the process of upgrading those from version 6.9. We already have the required support.

There are four people on the team, but for Linux especially, there are only two people. We're easily managing 500 to 600 servers for Red Hat.

When you are running your infrastructure on this, you can always find some discounts with local support, etc. There are always some discounts to match your budget. It is definitely affordable. 

When it comes to virtualization, there are different factors. There is not only Red Hat. There is also IBM, VMware, etc. The third-party vendors always manage to come up with a good offer. Our company can't say no to that, and it works out fine.

We also have IBM AIX, and when you compare these two, there's a huge difference because IBM AIX's support is quite higher than Red Hat's.

To anyone interested in using Red Hat for the first time, I would definitely advise starting with the GUI because now, the GUI option is quite good, and you can do all the things. After that, you can slowly start moving to CMD. For learning, there are a lot of resources available online, such as YouTube and LinkedIn Learning, whereas Red Hat Academy is quite expensive.

The biggest lesson I have learned from using this solution is that when you're using the command line, you need to be extra careful. That's because when using the command line, a single slash can make a huge difference. That's what I learned at the start of my career.

I started with Red Hat Version 5. Now they have version 9, which I haven't used, but if I just consider the evolution from version 5 to 8, 8.2, or 8.4, there has been a huge difference because, at that time, people were scared of using Linux, but now, things are different. There has been a revolution in terms of OS. A lot of things are being changed, but in terms of the things that we do, for us, it is the same because we are doing system administration. As a system admin, there is nothing different for us. We are doing the same things again and again because the applications require the addition of storage.

There is also a change in terms of security features. If I compare the old versions with the new versions, in old versions, adding any exception in the host firewall was a real task, but now, things have either become smooth, or we have gotten used to it. Overall, for me, things have become easier. They are getting more and more secure, but with the vulnerabilities and the assessments that have been done, we need to keep updating. Now, everything has caught up with the latest security required in the market.

In our environment, we're using virtual servers. There are no physical ones. We are shifting to containers in my current organization. Most of the applications we are using are containerized, and it has been easy for us to manage those applications. However, we also require some in-built applications, and for that, a change in people's mindset is required. It's not about the OS; it's about the people who do the development. It is becoming a bit hard for them because they were using a different platform previously, and now, they need to move to the Linux platform. It is a little bit different for them.

Overall, I would rate it an eight out of ten. When comparing it with AIX, AIX is a bit easier in terms of use and it also has the Smitty tool.

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

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

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

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

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

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

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

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

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

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

We have been using RHEL since 2016. 

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

I would rate this solution as nine out of 10.