We provide it as a service for multiple Dutch government agencies, so we are not really the end user of OpenShift. We only use it a little bit. We mainly just install it for our end users. They use it for all kinds of government work. It is being used for critical work and all kinds of things.

It is mainly for application modernization. We want to be much more efficient as a government. We want to spend the least amount of money on IT because it is all tax money. We need to optimize our deployment as CI/CD, security, etc. OpenShift is helping with that. If you see what we can do now with OpenShift in terms of application development, the speed of delivery has increased a lot for our customers. There has been a good benefit.

We use OpenShift Container Platform's GitOps functionality. It helps with faster development. It is more secure, but it also depends on how you work with it and how you use it. You need to do extra things to make your development more secure. 

We have seen some time savings. For example, we are installing HashiCorp Vault, and we are doing it just on Red Hat Enterprise Linux VMs and OpenShift. The deployment on Red Hat Enterprise Linux VMs with Ansible takes 35 minutes, and on OpenShift, it takes three minutes, so that is a big difference. In the end, it is exactly the same deployment functionality-wise.

OpenShift Container Platform has made our development lifecycle faster. The time saved depends on the complexity of the application, but the deployment time is very fast. That is the main difference.

OpenShift Container Platform has not helped us deploy more apps, but it has made the deployment easier.

It is a little bit hard to determine which feature is the most valuable for our customers. We are never sure what our customers are doing with our OpenShift clusters. For us, the fully automated upgrades are valuable. We have to maintain the clusters in production. For us, it is very important that it does not take too much time to manage all the clusters and do life cycle management and upgrades. Since OpenShift 4, the upgrade path has become one of the most important features for us.

From a technical perspective, it has become a very good product. Since 4.9 or 4.10, it has become a very stable product.

My grief with Red Hat is that they are taking all open-source products and rebranding them as if they are their products. I get questions from our customers. They ask questions such as why are you using OpenShift? Why go for vendor lock-in? I have to explain that there is no real vendor lock-in. They should tone down the aggressive branding a bit.

At times, we also have some problems with getting the proper attention for specific bugs. Red Hat should work on that. We are not big customers of Red Hat, but sometimes, we have severe bugs. We are very innovative, and sometimes, we have to wait for a long time to get proper attention. Red Hat should improve on that.

Red Hat sometimes shifts its focus. We are moving our entire platform from OpenStack to bare metal, so we were running OpenShift on bare metal. They should improve their installers, and they should not change these installers all the time. They can maybe have two instead of four. They have shifted their attention to public clouds, so we now have to wait for our RVs, which is sometimes annoying.

We are not using the Red Hat GitOps operator. We are using the ArgoCD operator because the GitOps operator provided by Red Hat is too old. Our customers are asking for a certain functionality, and the Red Hat operator is lagging behind. It is the same with their Single Sign-On. We are not using Red Hat Single Sign-On because the versions are too old. They should speed it up a bit.

I have been using the OpenShift Container Platform since 2017.

It has become very resilient. We have had some very severe issues. We were very early in adopting OpenShift 4. Red Hat told us that we need to stop using OpenShift SDN and use OVN. We did that, and it became a nightmare. OVM was a beta when we put it in production. We had a lot of issues with it, so we migrated to Calico. We have some trust issues, not from the OpenShift perspective but from the networking side. We have critical workloads, and the clusters just crashed. It was a big problem, so we decided to migrate to Calico. Since then, we do not have any network issues. I know OVN has improved since 4.14 or 4.13, but for us, it is too late now.

It is perfect. You can easily add some resources, but I do wonder why the control plane uses so much memory. We have clusters with 100 nodes. Very soon, we need to upgrade the control plane to 32 gigs per master node. I am just wondering why that is necessary. We get a lot of questions from our customers regarding why our control plane is very expensive. It is designed by Red Hat. They can improve a bit on that.

We have a technical account manager. That works very well for us. Mainly when we moved to OpenShift 4, which was an entirely new product, it was very good to have a technical account manager. He could help us with all kinds of bugs and things. It is working out very well, so we decided to keep them.

On the support case side, I have different feelings. Our experience depends on at what time of the day we file a support case for a severe issue. The support engineers from the United States are the best, but sometimes the support engineers from the other parts of the world seem less skilled. They take longer and ask all kinds of stupid questions. I have had a lot of discussions with them where I have told them that we have a highly qualified engineering team. We know a lot about their products, so they should not ask me all these no-brainer questions. There is a big difference.

We also use Red Hat Key and other things. There are various issues with them, but we do not get the attention. They should fix the issues. If something is filed as a critical bug, I have to call Frank and I need to call Tom to do something about it. I have to ask maybe five or six times and then the ball gets rolling. That is my main concern with Red Hat.

Positive

We switched because of the ease of operations on OpenShift. We had do-it-yourself Kubernetes. We were also CoreOS Tectonic users. We have also tried different products such as Rancher, which is a good product but I am not very experienced with it to make a comparison.

When we started in 2017, we started with open Kubernetes, which is basically do it yourself. It gets really hard. We did do-it-yourself Kubernetes for a couple of months or maybe about a year, and then we decided that it was not the way to go. We were looking for more automation, and then CoreOS created Tectonic. We were using Tectonic, and then Red Hat came along and took over CoreOS. Tectonic just dropped dead, and we had a huge issue. We could not get support anymore. We were forced to go to OpenShift 3.11. It was a real nightmare. So, we had a nice platform and then a horrendous 3.11 platform for two years. It was a nightmare to maintain, and then OpenShift 4 came along. Overall, it was a hard path with a lot of bumps.

It is fair to say that we were forced to go for OpenShift. We are a Red Hat shop, and we wanted a Red Hat distribution. After Tectonic problems, our CTO told us that we were going for a Red Hat stack, so we had to use 3.11. We were very disappointed in that. We knew 3.11, or 3.9 at the time, was not good. It only got better when OpenShift 4 came. Before that, we were not a happy Red Hat customer, but now we are.

The main advantage of OpenShift is the upstream Kubernetes. The most important feature for us is to completely or fully automate upgrades. From the application development side, the entire ecosystem is very strong. There is a total package with it. We can discuss with our customers if they want the entire Red Hat ecosystem or not. We have customers who want to use the entire ecosystem, and then we have customers who want to be more agnostic. It is also difficult for my team to keep that balance right. It is the most difficult part.

To install OpenShift, we have a two-phase process. We are using Ansible to bootstrap things on OpenStack or bare metal. We do the post-configuration with ArgoCD. On the bare-metal side, it takes longer to install OpenShift because they are all physical nodes. They take longer to boot. In virtual environments, it takes about 15 minutes. We have an entire OpenShift cluster, and then we just deploy with ArgoCD.

On our current platform, we install OpenShift on OpenStack, so we are using the UBI installer. It was also a problem for us. We wanted to use the IPI installer but had to use the UBI installer. It meant that we had to do a lot of things ourselves. In the end, it gave us more flexibility. They then changed the IPI installer to make it more flexible, so we can go back to the IPI installer, but teams cannot switch the installers all the time. For our new platform, we are going to migrate all our OpenShift clusters to bare metal with hosted control planes. For the bare-metal clusters, we are using the agent-based installer.

We do it all ourselves. It is very important because you get to know the product very well.

It is a bit hard if you are a cost-neutral organization. We are working for the government. We do not have profit goals. We always have to be able to justify why we made these costs and what the reasoning behind them was. It is a lot of money. I do not have the data, but we are using Red Hat because of the innovation and stable products. We also get good support, which is important. If we are using critical workloads and shared instances, we need to ensure that we have a good partner.

We have saved a lot of time. We just migrated from and stopped using Ansible for GitHub-related things. We are still using Ansible for OpenShift. It is mainly for the bootstrap and the cluster, but for the GitHub stuff, we are moving a lot faster with OpenShift. If you build an application through Ansible, you need to figure out OpenShift LightSpeed and other things all by yourself. You need to sometimes write all the playbooks and all kinds of complex code in Ansible. It takes hours or weeks to get that done, whereas now, the application runs in minutes. In my experience, about 80% of the application deployment using OpenShift and GitOps is very fast. The last 20% is hard if you want to make it production-ready. Being a government organization, we have all kinds of regulations and compliances. That makes it harder, but it is still much faster. Also, by using the container technology, you can try a lot more on your development laptop to speed things up.

Its licensing is completely incomprehensible. We have special people within our company. They discuss with Red Hat subscription managers. It is too complex, and I do not understand it.

We are from the government, and we are trying to be as cheap as possible. Sometimes, I am just amazed at the amount of money that we have to pay. It is crazy.

In the beginning, we evaluated do-it-yourself Kubernetes, Rancher, and CoreOS Tectonic.

Overall, we are very satisfied with OpenShift.

I would rate OpenShift Container Platform an eight out of ten.

I use the solution in my company to run a lot of web applications. My company is moving all of its web applications to the solution. The product serves as a primary environment for applications.

The most valuable feature of the solution is that it has a lot to offer to developers, so they don't need to care about the infrastructure or basic setup of the containers, so you can just jump in and develop. The product can do many functions on its own.

I use Red Hat OpenShift Container Platform's GitOps functionality. In terms of the tool's GitOps functionality to help with a more secure and faster software development process, I would say that my company started using it for deploying the cluster, handling backup, and testing purposes. My company has started promoting the product to developers since we don't have enough in-house developers. Most things are project-oriented in our organization, and every developer might not have the tools or have never used such tools. My company has to promote the product and give it to the developers.

In terms of the time required to set up an infrastructure without Red Hat OpenShift Container Platform, I would say that if an infrastructure is present, our company just requests a new project, after which the next steps are all automated. The tool may take a longer time to provide a ticket than the real-time it does to provision.

The use of Red Hat Advanced Cluster Security (ACS) to more securely build and deploy cloud-native applications is a pain point for my company. My company would actually like to get Red Hat OpenShift Platform Plus but it is not yet available from Arrow. If the tool was available from Arrow, my company would have used the solution to manage our cluster security.

The use of Red Hat OpenShift Container Platform has made the development lifecycle faster for my company. I can't provide an exact number on how the development lifecycle has become faster, but I can say that you need to provision servers to prepare the environment for the developers and to give them access to open up firewall rules, so it works a long way in reducing the time from two weeks to one day.

Red Hat OpenShift Container Platform has helped my company achieve infrastructure cost savings, but it is hard to calculate. I know that as we had it on an on-premises infrastructure, it was there and paid for years ago. Red Hat OpenShift cloud services were on top of Red Hat OpenShift Container Platform, but at the moment, it is hard to say if the tool has helped my company achieve infrastructure cost-savings. If you look through the migrations and the measurements of the real usage on CPU, memory, and the applications on an on-premises model, it would be possible to lower the costs, but the costs may be more for administration or operations and for securing all the stuff. The aforementioned area consists of the product's real benefits besides the infrastructure.

My company is not driven by how many apps we are able to deploy with Red Hat OpenShift Container Platform. All new apps should be there, and our company is trying to follow it with the tool, but I would not say that using Red Hat OpenShift Container Platform means having more apps.

Comparing Red Hat OpenShift Container Platform with other Kubernetes platforms to make our company's Kubernetes environment operational, we tried EKS, which provided us with the infrastructure we needed. Red Hat OpenShift Container Platform has many benefits, and it has been a turnkey solution for me right from the start. Red Hat OpenShift Container Platform has been implemented on top of different stuff so as to have a full solution, but I would say that it is a turnkey solution with which you can start, as you get to have many things in place that are not there in in the plain Kubernetes. Red Hat OpenShift Container Platform offers a lot more for developers than what plain Kubernetes can provide.

I haven't thought about what additional features are required in the product, because in our company, we mostly use Azure Red Hat OpenShift. I believe that the documentation part is an area with certain shortcomings where improvements are required. From an improvement perspective, more documentation is required, along with a few functionalities that Red Hat OpenShift or native OpenShift offers.

I have been using Red Hat OpenShift Container Platform for five years.

My company has not faced any outages with the solution in the last three years. It is a stable solution. Though I might have faced a few issues with the product, it has never burdened the clusters, or the operations had some issues.

With just a few clicks, it is possible to scale up easily and directly from Red Hat OpenShift Container Platform itself. Even in Azure, you can scale up directly from the Red Hat OpenShift Container Platform, as the tool is very well integrated.

My company's supporter, Eviden, manages the communication with Red Hat's technical team, but I know that it is quite good. If you raise a ticket with the technical teams of either Azure or Red Hat, they take care of your issues. I rate the technical support a nine out of ten.

Positive

I know that the tool's deployment process is automated, and if one needs to test a cluster, it can be done with just one click, after which you need to wait for half an hour to 40 minutes until the infrastructure is there.

The solution is deployed on the public cloud services offered by Azure.

My company used services from Eviden, a service provider, for the deployment of the tool. Evident was formerly known as Atos. My company's experience with Eviden has been very good, and we have a good partnership with them. I feel that my company can trust Eviden with what we want while also getting informed of the troubles associated with the tool that may crop up in the near future.

In terms of ROI, I can say that my company now has a centralized solution which offers security. I have experienced ROI if I consider how the product gets installed and the high availability offered right out of the box, allowing us to scale up and scale out.

My company majorly uses Azure Red Hat OpenShift, on which we can deal with server instances, which can be cost-saving. If you buy the product for a year or three, you get a lot of discounts. Red Hat OpenShift Container Platform is not a cheap product and has almost the same costs when it comes to the licensing and subscription models offered to users. I feel that the product is worth its cost, especially since setting it up can be done with just a few clicks.

I have evaluated a solution called EKS against Red Hat OpenShift Container Platform. EKS provides you with the basic features in Kubernetes, so you need to work to have a usable infrastructure for developers, along with a lot of configuration on top for security. The aforementioned areas are already managed in Red Hat OpenShift Container Platform. Red Hat OpenShift Container Platform has been a more secure product from the beginning that you could just put to use.

There could be some improvements in the product, but overall, I would recommend it to others.

I rate the solution a nine out of ten.