The platform's most valuable features are its regulatory compliance and enterprise support. It does not offer significantly unique features compared to Kubernetes or Docker. The primary advantage is its extensive support and integration with Red Hat's solutions.

The product's setup process could be easier. 

We have been using Red Hat OpenShift Container Platform for approximately one year.

The product is quite stable and reliable, offering robust performance compared to other solutions.

We are currently working with a multi-cluster environment, and the product scalability and response time are impressive, with nodes performing optimally.

Compared to IBM support, Red Hat's support team is more responsive.

The setup process is considerably more complex than that of Docker or Kubernetes. Its multi-node cluster setup involves a more intricate and time-consuming method.

OpenShift's core-based licensing model provides significant benefits regarding enterprise support and scalability. Despite its high cost, it offers valuable features and support that justify the investment.

The product is expensive. 

I rate the platform an eight. 

Our primary use case for Red Hat OpenShift is to deploy applications. We utilize the platform to manage multiple pods and ensure seamless scaling of our nodes and servers to meet the demands of our high-availability applications.

The platform has significantly improved our organization by enhancing productivity and reducing the time required to deploy applications. It allows for faster deployment and continuous delivery, which has streamlined our development processes.

The most valuable features of Red Hat OpenShift include its integration with Kubernetes and the user interface, which enhances the end-user experience and accelerates the deployment process. These features contribute to increased productivity and efficiency for our developers.

The product could benefit from additional operators and tools integrated with OpenShift. Furthermore, enhancements to the user interface and including more features would be beneficial.

I rate the platform's stability a seven out of ten.

The platform is scalable. 

I have opened some tickets but did not receive the required technical support.

Neutral

The initial setup was complex. I rate the process a two out of ten.

The implementation was done in-house.

I rate the product an eight out of ten. 

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.