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

It was implemented in-house.

The deployment process is straightforward. I simply had to deploy the images using OC commands, and the process of connecting to OpenShift was remarkably fast and smooth.

The implementation was completed in-house.

For the OS component, we worked directly with Red Hat. However, we utilized a company called Bits, based in Elk Grove, Illinois, to handle the hardware provisioning and setup.

We have 8 to 12 people for deployment and maintenance. They handle the deployment and change of the environment in the data center. For DevOps, I have another team of probably 30 people. They develop solutions for customers.

They had Unix admins on site. They were implemented to bring in the Red Hat environment because of the similarity between Unix and Red Hat.

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.

The implementations are all completed in-house.

We're the integrators or implementors of the solution.

Implementation was done in-house by a team of three people.

Our organization is huge but I handle the setup for instances in our small data center.

The in-house team, consisting of four people, in my company takes care of the upgrade and migration parts attached to the solution.

One of our deployment models is on-premise, and the other is on the cloud. It's a hybrid. We have a big footprint on the cloud.

We use Azure because a lot of resources are already deployed on it. We can use all the features I build on RHEL, but you can scale up the infrastructure, depending on the demand. That's the reason why we use Azure.

For the upgrade process, we mainly use Ansible automation. Whenever we want an upgrade, we just go into the Ansible Tower, change the version, and make sure we are applying that to the right environments so that there's no outage. 

We are a local government organization. We have an account manager from RHEL, and we also have a local system integrator and a local partner. They are providing us local help for our requirements.

For purchases or subscriptions, we don't have any issues. We have multiple subscriptions for multiple products. Our local Red Hat partner takes care of all requirements. We just send the requests to them, and they take care of all subscription-related things for us. The whole process is streamlined.

We used some integration for the deployment. That's why it was so fast. We use a base image as the setup, and then, on top of that, we install some extra things. It’s just about cloning an image and starting it.

The solution does require maintenance, but nothing more than the usual. We need a team of four people with Linux knowledge to maintain the solution.

When it comes to provisioning and patching, it is pretty manual. The company uses VMware, and the process is pretty manual and involves a certain number of shell scripts. I know we're trying to adopt Ansible, but we're not very far along.

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 deploy the solution in-house for customers and it takes a few hours.

Ongoing maintenance includes applying versions on occasion to make sure processes aren't hanging, over consuming, or missing resources. 

Each client has a set of servers and databases, so maintenance might require two to six system administrators. It all depends on use cases including the number of systems, how critical systems are, and whether you need downtime. 

We used Red Hat's solution architect team, which is quite good. On our team, there were eight to nine people involved, mainly in the DevOps infrastructure and product solutions groups.

We used Red Hat with the OpenShift deployments to make sure we were doing it right, and then a lot of other things, such as Red Hat Enterprise Linux 8 or Red Hat Enterprise Linux 9, we just did ourselves.

In terms of our upgrade and/or migration plans to stay current, we are upgrading everything to Red Hat Enterprise Linux 8, and we are going to Red Hat Enterprise Linux 9 already. We are making that a product feature. We are using Red Hat Enterprise Linux for Edge for our remote deployments.

In terms of provisioning and patching, we deploy the base image, and then we use Ansible for the configuration behind it. For Red Hat Enterprise Linux for Edge, we use the OS builders to build out that same image. I use Kickstart to build the base image before the configuration.

It was implemented by Red Hat. In terms of maintenance, it does require maintenance, but once it is highly available, it's easily done.

The implementation was completed in-house.

We have an O&M contract that helped do the setup, and then we did consult with Red Hat on it. Guidehouse is the contractor that provides support for development in O&M. They've been a great team and partner to us. 

The implementation was completed in-house.

The implementation is completed in-house.

Our company implemented the solution in-house. Deployment time depends on the application and use case. 

Two administrators handle ongoing maintenance which includes installing patch files. 

We implemented it in-house.

We have four people that support it, although they do not work on it full-time. For example, the person who works on it most consistently also does work in the networking and firewall space, as well as identity management. We have more support staff for Windows within our environment.

The most recent change we made is a flag that had to be set on the kernel for some of the machines. Setting the flag means that you can patch it without having to reboot. This wasn't particularly problematic, although we had to make sure that it was in place because we now have patching occurring on a monthly basis.

In general, there is not much to do in terms of maintenance. The biggest drama has come from organizing upgrades to the application side that sits on top, rather than the operating system itself.

Our in-house IT department did the deployment. We have a separate IT department that leverages the training provided by Red Hat.

The solution requires maintenance, and it is a shared responsibility. They take different maintenance actions or tasks, and sometimes it's the operating system, database system, or application front band that needs maintenance.

We implemented Red Hat Enterprise Linux directly through Red Hat.

We follow a weekly patching schedule to fetch the latest updates. Our process involves applying these patches to the image and then generating containers, which we subsequently upload to our registry. We accomplish this using Ansible.

We worked directly with Red Hat for the deployment. We are already working on Red Hat Enterprise Linux 8 migration. Every year, whenever there is a major version release, we migrate to the major version.  

We deployed it on our own. 

It was deployed in-house. Three to four people were involved in its deployment.

In terms of maintenance, it just works unless you do anything special with it.

We did it on our own.

We did the implementation ourselves. The documentation is pretty good.

We use resources from Red Hat support. That's usually enough for us.

We regularly perform upgrades on our OpenShift clusters, typically on a monthly basis. When it comes to the Red Hat Enterprise Linux servers, we frequently update the images on our virtual machines to ensure that we stay current with the latest versions. We're actively working on implementing automation using Ansible to streamline and facilitate these tasks.

I did a lot of the implementation myself. 

We do everything in-house. We don't use any third-party help. Usually, I do all the deployments myself, but I also have an assistant. So, we currently have two people: me and my assistant.

It doesn't really require any maintenance. It just requires occasional patches. That's also handled by me and my assistant.

We have an engineering team that analyzes different products. During the analysis phase, we look for all vulnerabilities.

Once it passes all of those things, it becomes available in our internal protocol. We have different names where it becomes available in our source space to get deployed.

Migrations and upgrades have been straightforward. For example, OpenSSL has different versions that are not supported on RHEL 7, which we have right now. There is a version that comes built-in. 

We faced some issues, but we worked it out with Red Hat. They gave us a patch. 

We're moving to RHEL 8 now. We moved to RHEL 7 last year; we're going to RHEL 8 now. Next year, in 2024, we plan to move to RHEL 8.

We take 30 minutes to deploy the solution. It depends on the size of the machine.

We used professional services back in 2009 or 2010. But once we found that every vendor was looking for Red Hat Enterprise Linux, we added that skill in our department and now we are doing everything ourselves.

We usually deploy in-house as we have a trained team. Occasionally, little help is sought from the vendor teams, some of them have skilled professionals.

It was implemented in-house.

I worked with a Cloud hosting and deployment company that provided different Cloud services to their clients. They had servers based on Red Hat. It does require regular maintenance. We had a team of ten people.

I work with the two scenario