I use Red Hat Enterprise Linux for web application support, mainly OpenShift.

Azure is the cloud provider.

Red Hat Enterprise Linux is easier to manage because it can scale to a large amount and be managed across many platforms. This can lead to cost savings for our organization.

Red Hat Enterprise Linux has reduced the amount of management required on the Windows side.

Red Hat Enterprise Linux is extremely resilient because it is much more secure.

Red Hat Enterprise Linux's day-to-day functionality is very easy.

Red Hat Enterprise Linux has helped our organization save money by not requiring large-scale virtual machines, resources, or images.

OpenShift is the most valuable feature because it can be used to create applications on the fly.

The UI is not user-friendly and has room for improvement.

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

I am impressed with how extremely stable Red Hat Enterprise Linux is.

Red Hat Enterprise Linux's scalability is excellent.

Technical support is quick to respond, but sometimes tickets can get stuck in tier one for a while before they are escalated.

Positive

We previously used Windows but switched to Red Hat Enterprise Linux for cost savings.

The initial setup is straightforward. We can copy and paste any templates we need into the environment.

We have seen a return on our investment simply from receiving timely support when needed.

We purchased the Red Hat Enterprise Linux license via Azure and the vendor.

We evaluated CentOS but ultimately chose Red Hat Enterprise Linux because of the support.

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

When evaluating operating system options, keep in mind that Red Hat offers the best support.

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.

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 use the product for application hosting, availability, and CI/CD pipelines.

The solution has good availability and is easy to use. It saves money and resources like support staff.

The product should provide a portal to manage licenses.

I have been using the solution for more than five years.

The solution’s stability is fine.

The product’s scalability is fine.

The support is good.

Neutral

We have seen an ROI on maintenance. As long as our servers run, our company makes money.

We evaluated SLES and Windows.

We purchased the solution via a cloud provider. We use AWS, Google, and Azure. The resiliency of the product is the same as other products. 

The solution helped us reduce costs. We use SLES and Windows alongside Red Hat Enterprise Linux. Application support and vendor support for Red Hat Enterprise Linux are better than other products. 

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

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

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

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

We run our workloads and applications on AWS.

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

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

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

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

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

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

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

Red Hat Enterprise Linux is extremely stable.

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

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

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

Negative

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

The implementation is completed in-house.

We purchased our license from Red Hat.

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

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

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

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

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

I use the solution to build web applications.

The tool provides more support, resources, and documentation than other products.

The product is super easy to use.

The default settings are confusing. I often change these settings to avoid problems.

I have been using the solution for a couple of years.

The stability of the product is very good.

I did not have issues finding configurations and changing settings as needed. I haven't had any issues like bugs or downtime while using Red Hat Enterprise Linux. Overall, it was a good experience. Overall, I rate the solution an eight out of ten.

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

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

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

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

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

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

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

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

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

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

Neutral

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

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

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

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

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

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

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

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

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

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

I am a Federal Contractor. Red Hat Enterprise Linux is one of the FedRAMP-approved operating systems, so the government is comfortable with using it. That is why we use it, even though it is a bit outdated. Most of our software runs on Red Hat Enterprise Linux because we work in Identity Access Management. For example, Oracle Identity Stack runs on Linux, so we have to use Red Hat Enterprise Linux. We follow very strict security protocols, and we use Ansible to enforce them. Red Hat Enterprise Linux is the easiest way for us to do this.

Red Hat Enterprise Linux is a trustworthy and highly scalable operating system. The federal government needs an operating system that they can rely on, with enterprise support and long-term service. As well as being stable and well-known within the community.

I have not yet experienced a disaster recovery scenario, but resiliency is important, and risk is very reliable. The auto logs are very clear. Additionally, with those support communities, it is straightforward enough to understand what we are looking for and to eventually resolve the issue.

I actually like the in-place upgrade that Red Hat Enterprise Linux offers. It has made our upgrade process from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 much easier than we originally thought. 

I know that many people prefer in-house support, but I personally prefer Red Hat's support. It is easy to get in contact with their support team.

Even though it is not directly related, the fact that Red Hat Enterprise Linux and Ansible are closely related makes it easier for us to move forward.

The package management, repository, and satellite repository are easy to use.

I am a bit biased because my client is air-gapped. This means that we cannot connect to the internet, so all of our operations are disconnected. I would like to see better support for disconnected operations. For example, the in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 initially relies on a lot of online resources. This makes sense, but it would be nice for a consumer or integrator like me to be able to say, "Hey, we need an offline solution so we can upgrade our government clients on-premises." Red Hat does provide instructions on how to create a repository, but the instructions are not very clear. This leaves us scrambling to figure out why we are missing a repository in our satellite image. Red Hat should provide a way to mirror repositories or at least provide a solution for us to bubble up packages throughout the entire process.

I have been using Red Hat Enterprise Linux for four years. We started with Red Hat Enterprise Linux 6, and we upgraded to Red Hat Enterprise Linux 7 in an airgap environment. We are currently in the process of upgrading to Red Hat Enterprise Linux 8.

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is scalable. It is deployed in a 10,000-plus enterprise company.

The support team is always direct and easy to find. Their answers are so helpful that I have not yet had to call them. I also appreciate how they approach troubleshooting. They don't assume that you're doing anything wrong. Instead, they try to educate you on how to fix the problem. In my experience, the support team has always been very positive.

Positive

I have experience with most Linux operating systems, including distributions like Apache, Debian, CentOS, Fedora, and others. From my perspective, Red Hat Enterprise Linux is not necessarily the top standout product, but I know that it is a product that I can rely on. It is the standard image that enterprise users in the community will use. We can rely to a degree on the standardization of how packets are used to support it. However, it does not stand out to us as much as the other products. Nevertheless, I know that it will have a positive partnership with us. Red Hat Enterprise Linux is a more suitable operating system for enterprise environments in terms of stability and reliability.

We are currently in the process of reviewing our initial solution for upgrading from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. The in-place upgrade for the airgap environment is an area where we are still struggling to understand the documentation. However, Red Hat has been very supportive and has offered us pathways to move forward. We do not have much to say at this time, as we are still in the middle of the process.

When we upgraded Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7, it took us around six months due to external factors not related to Red Hat Enterprise Linux.

Our client has a direct subscription to Red Hat.

I give Red Hat Enterprise Linux an eight out of ten. I am not a firm believer that everything is perfect right out of the gate. Everything can be improved. I am a little biased. I wish there was better support for offline environments. I understand that I am in the minority in this case, as everyone is connected to the internet now. However, as a federal contractor and integrator, we have requirements that we must meet. It is not fun having to download binaries offline and then figure out how to set up our own repository. These are not straightforward tasks like Red Hat telling me what to do. We just wish it was easier to do things like patch management. Perhaps there could be more support for air gap environments. These are not environments where we can temporarily connect to the internet. They have never seen the internet.

Depending on our customer's environment, sometimes they have GovCloud, but we still use Red Hat Enterprise Linux images there. Sometimes the customer can't use that so we use the offering from CentOS. But we still try to match it with CentOS.

The reason why some clients don't use Red Hat Enterprise Linux on the cloud is not because of security concerns. I think it's more about cost and their current contract situation. They need a low-cost, open source alternative, and our recommendation would be CentOS. However, many clients are not ready to pay for the enterprise edition of Red Hat Enterprise Linux, so they may choose to scale back their plans.

I have not used the Red Hat Enterprise Linux knowledge base strictly. I have only used the Red Hat Enterprise Linux support.

Clients who use Red Hat Enterprise Linux on the cloud, typically use AWS GovCloud. As a government integrator, we strive to design our solutions in a way that does not lock our clients into any specific cloud provider. This is why we chose Linux, as it can be run on any cloud platform. This flexibility is important to our clients from a price contract perspective. For example, Amazon provides Kubernetes services, among other things. We try to figure out open source solutions or at least architecturally determine them and provide them to our clients. For example, we can tell them that they can move all of their GovCloud data to Azure or Google Cloud. Government agencies really like Amazon right now because it is FedRAMP. However, for other classes that are not government or commercial, we try to introduce them to the CentOS perspective so that they can get a taste of the upstream.

We do not use the image builder tool provided by Red Hat. Instead, we use the one provided by Amazon. We take a base image, coordinate it with Ansible, and provide it to any environments that have used the cloud. For on-premises solutions, we strictly use manual processes.

I don't have a perspective on the golden image, which is at least with our client. The parts that we use are always evolving, so we don't really maintain the golden image. We do have a relative backup of what we deployed to, but we don't necessarily have a strict golden image.

Migrating workloads between the cloud and the data center using Red Hat Enterprise Linux is not entirely applicable to us. We did migrate from on-premises to the cloud at one point, but migrating from Red Hat Enterprise Linux on-premises to Red Hat Enterprise Linux in the cloud was not a concern for us. We knew it would be stable and fine. The main concern was migrating our customer data from our enterprise to the cloud.

If someone is looking for an open source cloud-based operating system for Linux instead of Red Hat Enterprise Linux, I would like to eventually drive them over to Red Hat Enterprise Linux, but I would recommend starting with CentOS. CentOS is a good gateway OS because it is very similar to Red Hat Enterprise Linux, and the knowledge transfer between the two is very straightforward. This makes it a good choice for users who are new to Linux, or who are looking for an OS that is compatible with Red Hat Enterprise Linux.

We use the product to use the virtual servers.

Compared to Windows, the solution is much simpler. The product is easy to use.

The solution should provide demos so that users can learn to use it and improve their environments.

I have been using the solution for three to four years.

I have no complaints about the stability. It is good.

I have no complaints about the scalability.

We use the on-premises solution because we work for the government. We cannot use the cloud version because we have to maintain confidentiality. We are using versions six, seven, and eight. We also use Windows in our organization. Overall, I rate the solution a ten 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.