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.

Whenever we onboard or deploy services that talk to Oracle Database, they take a lot of time to become active and serve the incoming request, so it would be good to see some improvement here. This could be an OpenShift issue or an internal network problem within our organization.

OpenShift is an excellent platform, but AWS is fighting a tough fight, so Red Hat must continually improve its product.

OpenShift is not very old. They have built an entire layer on top of Kubernetes. Getting the solution quickly and troubleshooting quickly are both areas where I think it needs some work. 

It wasn't very problematic for us because we were getting the solution. They also needed to do some experiments in their own lab, because our use case was a little different, and we were one of the few who were implementing it for the first time with Cloud Pak.

I'm not sure if this is an issue with OCP, but it takes time to deploy. I'm not sure because we have pipelines and Jenkins jobs that deploy the microservice so it takes time. It can take 10 to 15 minutes to deploy a microservice. The CI/CD process takes a long time, and if it's because of OCP, that is something that can be changed.

My impression is that this solution is pretty expensive so I think the pricing plan could improve.

In my experience, the issues are not always simply technical. They do stem from technical challenges, but they struggle with the topic of adoption. When you encounter all of the customer pull, there are normally several tiers of your client pop that can adopt either the fundamental features or a little more advanced ones.

The majority of the time, the challenge is determining how to drive adoption, how to sell the product to the customer, and how much time they can spend to really utilize those advanced features. If we get into much more detail, but this is from my perspective as the platform engineer and not the end customer, the ability of the end user to be able to debug potential issues with their application That is arguably the most important, let's say, work throughput in my area.

There is room for improvement with integration.

The solution does not work on a route-wise NFS.

There should be a simplification of the overall cluster environment. It should require fewer resources. Just to run a simple Hello World app, it requires about seven servers, and that's just crazy. I understand that it is fully redundant, but it's prohibitively expensive to get something simple going.

We've had a very difficult time going from version 3 to 4. We need to go to version 4 because of multiple network segments that may be running in a container and how we organize our applications. It's very difficult to have applications from different domains in the same container cluster. We've had a lot of problems with that. I find it to be an overcomplicated environment, and some of the other simpler containers may very well rise above this. 

At the service level, I don't see a very granular level of security as compared with the container-based clusters. It is at the Kubernetes level, not at the service level.

Also, when I compare it with the other container or Kubernetes technologies, we have pretty good documentation from OpenShift, but with the recent trend of cloud-native, fully managed serverless services, I don't see much documentation about how a customer should move from on-prem to the cloud, or what is the best way to do a lift-and-shift. Even if you are on AWS OCP, which is self-managed infra services, and you want to use the ROSA managed services, what is the best way to achieve that migration? I don't see documentation for these kinds of use cases from Red Hat. There is some room for improvement there.

The price needs to be improved in OpenShift Container Platform.

When I choose this, the product is the first factor that we have to make a long analysis to compare the real cost for the other services. However, price is high.

I have only been working for two years on OpenShift Container Platform, and I have only seen good stuff so far. Hopefully, in the next two years, I will have a bit more hands-on experience to find out some pain points in the product.

There are no perfect tools. Many things can be done better in a product, but I don't know how to make it possible. Once I have done enough with the tool, I should be able to give you a bit more insight into the product's pain points.

The interface could be a bit more useful or better. The product's interface is a bit buggy.

OpenShift Container Platform needs to work on integrations. 

The setup process is not great and could be better.

A lot of improvements are required in OpenShift when it's deployed on a public cloud such as AWS, GCP, or AKS. 

OpenShift has certain restrictions in terms of managing the cluster when it's running on a public cloud. For example, identity and access management integration with the IM of AWS is quite difficult. It requires some open-source tools to integrate. This is one area where I always see room for improvement. 

In addition, the RBAC access is only controlled by the OpenShift internal mechanism, whereas the authorization part can be handled by any public cloud. We are already managing and maintaining users in the cloud environment. So, a repetitive or duplicate RBAC mechanism is not required. 

The support costs are too high. 

I want to see more incorporation of native automation features; then, we could write a code, deploy it directly to OpenShift, and allow it to take care of the automated process. Using this method, we could write one application and have elements copied or pasted to other applications in the development process.

There are some gaps in the solution's security, so there is room for improvement in the security and compliance features. Protection against ransomware attacks would be welcome, much like in Google Apigee.

One area for improvement is that we can't currently run Docker inside a container, as it clashes with security consents. It would be good if we could change that.

The stability of the console could be improved. 

The UI could be more user-friendly to drive tasks more effectively through the interface.

The monitoring is problematic. The product monitoring tool does not work for us. We had to purchase the Dynatrace solution to monitor our product and our applications, and this is a weakness of OpenShift Container Platform. If there was some orchestration with mini services because microservices can be complex.

We've encountered challenges when transitioning applications between these environments. For example, an application that runs smoothly on standard Kubernetes might face compatibility issues when ported to OpenShift. This variation has posed some challenges for us, and it's something we're actively addressing. I think it's important to create a plan to ensure seamless compatibility between applications running on vanilla Kubernetes and those on OpenShift. This involves delineating features unique to each platform, such as those specific to vanilla Kubernetes and the additional capabilities offered by OpenShift. The goal is to make it feasible for an application designed for a more basic Kubernetes environment to run smoothly, providing valuable flexibility.

The introduction of OpenShift slowed down our development life cycle due to compatibility issues.

It is difficult to deploy the OpenShift cluster in a bare-metal environment. For example, when there are errors during the cluster deployment, it is hard to find the error on any documentation. So, from the cluster deployment perspective, there could be improvements.

Also, the machine config and machine config tools need improvement. The machine config tool implements changes related to files over the worker and master nodes in OpenShift. However, sometimes it starts without warning, and it is unclear how the error can be fixed.

In terms of additional features, it will be good to have the support of the CNI or OVN for the Multus CNI. Currently, in OpenShift, the additional networks added by the Multus and the pods do not support the OVN CNI plugin. OVN is supported in OpenShift, but only for the non-Multus interface, which is the primary interface of pods.

Everything is good. I don't see any need or any improvement that can be done. They cover CI/CD and I have not seen something which is missed in this product.

The initial setup can be hard.

It takes some time to learn everything. There's a learning curve. 

The monitoring and logging could be improved. I think it would help developers in terms of provisioning the database and the whole development lifecycle.

We encounter difficulties while accessing the environment and managing the cluster. This particular area needs improvement.

From a networking perspective, the routing capability can be matured further. OpenShift doesn't handle restrictions on what kind of IPs are allowed, who can access them, and who cannot access them. So it is a simple matter of just using it with adequate network access, at the network level.

It should be possible to whitelist IPs so that you can allow and restrict access to the API. That would be a fantastic feature. OpenShift would then encapsulate the entire security and access. This is one improvement that I would seriously want our client to have, and for that reason, I have joined the OpenShift community, and it is a project I could probably work on myself. 

The second thing is that deployment is more of a strategy rather than a feature in OpenShift. Although you can create different routes, and it works fine, it is not an innate feature of OpenShift that it understands that you want to run specific versions of the same service as needed. Though you can define routes to serve different versions.

OpenShift needs to improve their container storage. In the next release of OpenShift I would also like to see simplification of Calico BGP with the container network and integration with MinIO, Portworx, and Rubrix.

OpenShift Container Platform is an expensive solution, and its pricing could be improved.

Container Platform could be improved if we could aggregate logs out of the box instead of having to do it through integrations with other products.

There will be things that can improve, however, at this stage I cannot give a point or two. Maybe after a few months, I can give more details.

One improvement I can suggest is for the people who are not very competent with technology, for the product to give some tips on the screen, to make it easier for them. Things are there and the documentation is there, however, there still needs to be quick guides available. Then it will be easier for people to adapt and learn. Rather than going to big documentation, if there is some quick help or quick guide available and then it would help people to quickly adapt and learn.

It still has to improve compatibility with a couple of more platforms. It works with many however we are still trying to improvise more on a couple of other platforms. Integration seems to take a little bit of time. It would be nice if it was expanded and simplified a bit.

OpenShift's documentation could be better. It's difficult to document everything you need in a specific use case. You have to seek some support or spend a few minutes trying to figure out what's going on.

Another thing that bugs me is that they removed the software in NFS storage. I don't understand why because this is a common type of storage. I am having problems with that, so I wish they would put it back. 

The complexity of the installation could be reduced. While we got the necessary support, the instructions could be clearer.

It has an option to install OpenShift without connecting it to the Internet. We tried this, but it was very hard. We couldn't manage to use that option. We wanted to use it offline for installations, updates, upgrades, etc., but we didn't find the offline installation and updates easy. This could be better.

The solution has pretty good features overall. I can't recall if there are any that are lacking.

The pricing is quite high. It would be nice if they could make it more competitive.

The solution needs to introduce open ID connect integration for role-based access control.

OpenShift Container Platform could improve by having better integration.