![Gravity [EOL] vs. Red Hat OpenShift Container Platform report](https://www.peerspot.com/assets/media/images/icons/pdf-80836ec5.svg){kind=icon}
![Gravity [EOL] Logo](https://images.peerspot.com/image/upload/c_scale,f_auto,q_auto,w_64/wmpcvfzq5emrm2e7yo98aqoctp8a.jpeg)
![Gravity [EOL] Logo](https://images.peerspot.com/image/upload/c_scale,f_auto,q_auto,w_30/wmpcvfzq5emrm2e7yo98aqoctp8a.jpeg){kind=small}
![Gravity [EOL] Logo](https://images.peerspot.com/image/upload/c_scale,f_auto,q_auto,w_40/wmpcvfzq5emrm2e7yo98aqoctp8a.jpeg){kind=small}
OpenShift has a pretty steep learning curve. It's not an easy tool to use. It's not only OpenShift but Kubernetes itself. The good thing is that Red Hat provides specific targeted training. There are five or six pieces of training where you can get certifications. The licenses for OpenShift are pretty expensive, so they could be cheaper because the competition isn't sleeping, and Red Hat must take that into account. There are a few versions of OpenShift. There is the normal OpenShift and an OpenShift Plus license. Red Hat could think of how to connect those two subscriptions because, with Red Hat Plus, you have one tool called ACM (Advanced Cluster Management), where you can manage multiple clusters from one place. We deployed this functionality by ourselves, but if you don't pay the license for Red Hat OpenShift Plus, you'll lack this functionality. If you have a multi-cloud environment and you have a lot of work to do, it would be a plus if the Red Had OpenShift Plus license came in a bundle with the regular solutions. This ACM tool should be available in the normal subscription, not just the Plus version. There are new versions on an almost weekly basis. I found myself that the upgrading of OpenShift clusters is not a task that will successfully finish every time. It's a simple and quick, but not reliable process. That's why we use multiple clusters. We use v4.10.3, but we want to move to v4.12.X. The upgrade process itself can fail, and we don't have backups of our OpenShift cluster because we have backups of all the Kubernetes manifests on GitHub. We destroy the cluster, bring up a new one quickly, and apply those scripts. The upgrade itself could be more resilient for us as administrators of OpenShift to be sure that it'll succeed and not occasionally fail. They can improve the reliability of their upgrade process. They also have implementations of some Red Hat-verified operators for a lot of products like Elasticsearch. They're good enough for development purposes, but some of the OpenShift operators still lack resilient production-grade configurations. Red Hat says that we have a few hundred operators, but I believe that only half of them are production-grade ready at this moment. They need to work much more on those operators to become more flexible because you can deploy all of them in development mode, but when we go to production grade and want to make specific changes to the operator and configuration, we lack those possibilities.
