The use of the solution keeps varying, considering that we have web apps and a lot of homegrown stuff as we build a lot of our own apps. My company also uses Red Hat Enterprise Linux (RHEL) for the operating systems for a lot of our other applications that we use for authentication purposes and so on.

I can't really talk much about how the product has benefited the organization since it is not in my wheelhouse, and I mostly deal with the area of configuration management and the automation of configuring it. In my company, we have a Unix team I work with, and when they want to automate processes, then they come to me and I help direct them.

The solution's most valuable feature revolves around its simplicity, especially when maintaining it, which is an easy process.

I have not seen anything in Red Hat Enterprise Linux (RHEL) that causes any queries or doubts in my mind, so I am not really sure if I see any need for improvements in the product at this point, especially when I have good communication with the sales teams and support. I have also recommended the changes I want to see in Ansible, an area where my company sees progress. There is nothing my company is disappointed about regarding Red Hat Enterprise Linux (RHEL).

I would like to see a better way to organize the jobs within Ansible, specifically with the automation platform. Right now, in Red Hat Ansible Automation Platform, everything is just flat as there are no directory structures or folders and no ways to designate specific jobs for specific things as everything is in one big pile.

With Red Hat Enterprise Linux (RHEL), my company has not seen anything requiring improvements. My company is really happy with Red Hat Enterprise Linux (RHEL). My company is still in the migration process right now since, from all of our seven boxes, we are moving on to the eight and Red Hat Enterprise Linux (RHEL) 9. The aforementioned process has been really smooth and slick. My company likes the speed and simplicity of the OS.

I have been using Red Hat Enterprise Linux (RHEL) for twelve years. My company has been using the product since before I joined.

It is a stable solution.

It is a scalable solution.

I went to have dinner with my sales team the previous night, and we just had a chat, after which I got to know some professional services offered by some people willing to come and help our company with the solution if required. Based on the aforementioned area, I can rate support as ten out of ten.

My company has experience with AIX, Solaris, and Windows. My company switched over to Red Hat Enterprise Linux (RHEL) because people wanted it, specifically the app developers. My company uses Red Hat Enterprise Linux (RHEL) based on supply and demand factors. You just build what is needed for the infrastructure side or when you are in the operations.

The product's deployment phase was simple.

There is a different group in my company that has built up a strategy to deploy the product, so I don't have to do anything in its deployment phase. To request a new system is just a matter of filling out the ticket and submitting it easily, after which the box is built, which is great.

The solution is deployed on an on-premises model.

The deployment phase for the tool was carried out with the help of our company's in-house team. The product was deployed with the help of vRealize Orchestrator Appliance.

In terms of the ROI associated with the product, I would say that with a lot of stuff I do in the company, I also get involved with the patching side, especially the patching of servers. I can patch 1,500 Red Hat Enterprise Linux (RHEL) boxes in the time it takes me to patch ten boxes from Windows. Patching in Windows is bad. Being able to patch Red Hat Enterprise Linux (RHEL) is simple since I think the most I have ever seen it takes is around 35 minutes to patch a box. When our company started to move towards a more containerized approach, we saw that being able to have your container or your OS can open a whole new world. Being able to spin up systems and have multiple systems that are already pre-patched, I don't have to have downtime for the enterprise.

There were a couple of operating systems, including CentOS, which my company looked at before choosing Red Hat Enterprise Linux (RHEL) as it offered a strong support model. The consistency offered by the Red Hat Enterprise Linux (RHEL) was also one of the other reasons why my company chose it over other tools.

Though my company does not currently have a hybrid cloud environment with the tool, we are working on it since regulatory compliances in the banking sector require us to stay compliant. My company is not in a place where we can just jump into cloud infrastructure, but we do hope to do so in the future. Presently, the product is on an on-premises model.

As I am not required to deal with the developers in our company, I don't know if the product has helped centralize developments.

My company uses Red Hat Enterprise Linux (RHEL) for containerization projects. The product has made dealing with containerization projects easy for my company since we get to use a lot of Kubernetes and Docker platforms that snap right into Red Hat Enterprise Linux (RHEL) and works.

Considering the built-in security features offered by the tool for risk reduction, business continuity, and maintaining compliance, I prefer Red Hat Enterprise Linux (RHEL) over a lot of other products. Our company is like an Active Directory shop, so we are doing a lot of tying to it, which is a little bit disappointing, but it is just business. I like the security end of Red Hat Enterprise Linux (RHEL). I also like the way the file handling takes place along with its management part, so I have no issues with the tool.

Speaking about the portability of applications and containers built on Red Hat Enterprise Linux (RHEL) to keep our organization agile, I would say that it is something that will happen in the future as my company is a slow adopter. I am not really sure why it has been slow. My company does have a new organization that is really focusing on opening up new avenues so that we can actually be more agile and have the ability to move to things like OpenShift and having our containers offer more high availability while not having any downtime.

I don't use Red Hat Insights.

If I have to speak to a colleague who is looking at open-source cloud-based operating systems for Linux, I would say that CentOS or Fedora are good options since both products have had an association with Red Hat Enterprise Linux (RHEL) for a long time. I personally like and prefer CentOS.

I would not be able to comment on whether the Red Hat portfolio has affected our total cost of ownership across our enterprise landscape because we just spin them up and keep building them. My company was primarily an AIX house, using Solaris and a lot of Windows boxes from Windows. Right now, my company has gotten rid of the AIX and Solaris systems, and now we are down to about a 50-50 split when it comes to Windows and Red Hat Enterprise Linux (RHEL). There have been times when we have had more Red Hat Enterprise Linux (RHEL) boxes in our company over the ones from Windows. I can see that in the near future, my company is going to be more of a Red Hat Enterprise Linux (RHEL) shop than an organization that has boxes from Windows.

In terms of the deployment model, I would say that my company has three data centers, mostly where VMware is used.

I rate the tool a ten out of ten.

I use the solution in the company to build a lot of our software environments, so we keep different baselines on it. Right now, I'm working on setting up and installing Ansible manually, so I haven't used Red Hat Ansible Automation Platform yet, a reason why I have been still using my Red Hat Enterprise Linux (RHEL) server.

In terms of features, I found it great when I talked with Linux subject matter experts about Ansible. They further mentioned that it was native to Red Hat, which is why it wasn't going to bring over more packages or modules. The packages or modules in the tool are already there but are just not enabled because they weren't being used before I asked about them. It is super easy to enable the tool's packages or modules when I want to start messing with it.

Red Hat Enterprise Linux (RHEL) has helped me centralize development because it has a standard, which is why my company can't really have the option to mess with its different technologies. Our company's customers don't want to use Ubuntu or any other such operating systems, which is why my company has to use Red Hat Enterprise Linux (RHEL). I guess the tool is easily centralized because that is its standard, and that is the only option one has unless someone wants Windows, but again, developers don't want Windows, and so there are no other options.

Our organization has a team to take care of the containerization part. I am mostly on the infrastructure side, but my company has started to ask me for Podman Desktop and all these different container platforms, and I haven't used any of them yet.

If I dissect the built-in security features of Red Hat Enterprise Linux (RHEL) for risk reduction, business continuity, and compliance, I would say that we use VMware for risk reduction so that we have a high availability. On the top of my head, I think the Linux team probably knows more about reducing risks. Our security team has all these STIGs they want us to apply, so I don't know how much manipulation they actually have to do.

If I dissect the built-in security features of Red Hat Enterprise Linux (RHEL) for risk reduction, business continuity, and compliance, I would say that we use VMware for risk reduction so that we have a high availability. On the top of my head, I think the Linux team probably knows more about reducing risks. Our security team has all these STIGs they want us to apply, so I don't know how much manipulation they actually have to do. For business continuity, my company uses VMware, considering the ease of making snapshots of our environments, but I believe we could probably do the same with different operating systems. In our company, we just take lots of snapshots, and then if we have another VMware instance, we could just build it right back. The only compliance I know about was associated with our company's customer and their STIG requirements, but I don't know how Red Hat Enterprise Linux (RHEL) helps with it, especially considering that in our company, we have to manipulate it and how we want to do it.

In terms of the portability of applications and containers built on Red Hat Enterprise Linux (RHEL) to keep our organization agile, I would say that we have an applications team that would do it in our company. I just make sure that our company's VMs have OS and network connectivity since there is a different team that takes care of the applications.

Right now, since my company is in an air-gapped on-prem network, it is really tough to go through all the RPMs that we have to have based on different STIGs. Whenever in our company, we have to install the tool, we see that something or the other is missing, and so of the hundreds of things mentioned in the list, we have to find whether we need a particular RPM or if we need to take this one out, and that is always a trouble for the team managing Linux in our company.

I have been using Red Hat Enterprise Linux (RHEL) for more than five years.

When I spoke to one of the speakers the other day, who was a software development manager, I was told how much one could trust Red Hat Enterprise Linux (RHEL). I believe that Red Hat Enterprise Linux (RHEL) is considered a standard for a reason.

I believe that if you have enough license to support the product in your environment, then you can scale the product depending on how big your license is, and it is a super easy process where one can roll out a whole bunch of VMs and VMware.

As my signature block comes with Lockheed Martin, I think the tool's support team has been pretty attentive. If I go to a wide-scale service and once Red Hat Enterprise Linux (RHEL) sees what kind of a customer I am, I get to go to their specialized sectors, and the support has been pretty fast. I have had no issues with the product's support team. I don't use the product's support services very often. I have mainly dealt with Red Hat's support team for Ansible. I rate the technical support a seven out of ten. When I was asking the tool's support team questions when I was off the internet, I just kind of felt weird about it. For any service I ask for from the support team, I have to manipulate it depending on what we need for our company.

I have not previously used any other product, and I have worked for the government for the past twelve years using Red Hat Enterprise Linux (RHEL).

The deployment of the product has been super easy, but when we do it through VMware, I just make a VM, and then load an ISO image, after which the deployment is done. The tool's deployment is super easy, and I am pretty much a novice when it comes to Linux.

The solution is deployed on an on-premises model.

My company did not seek the help of a third party to depot the product. The deployment was carried out by our company's employees, who have been around for decades.

The government buys the product for our company and provides us with the license for the solution.

For a colleague who is looking at open-source cloud-based operating systems for Linux, I would say that Red Hat Enterprise Linux (RHEL) is a cool product for small businesses outside of the government. I work for the government, where Red Hat Enterprise Linux (RHEL) is the standard, so if my colleagues are in the government, I would tell them they have no other options.

I am not sure about the product's deployment model since it is kind of ad hoc in nature. If a developer needs another VM, our company just provisions it through VMware, so we don't have a large-scale deployment model across different availability zones. We have our program, after which we wrap it all up and then ship it out to the customer.

As I have not compared Red Hat Enterprise Linux (RHEL) to any other operating systems in the market, I rate the tool a nine out of ten.