I would like to see advanced cluster management added in future releases, such as a single pane of glass to manage multiple clusters without needing to pay an extra subscription for it.

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.

There are several areas where OpenShift could improve. The interface has numerous UI bugs that need addressing. 

Furthermore, the latest version has deprecated the deployment config, which has its own advantages compared to the deployment container. 

Lastly, there is no built-in auto-scaling plugin at the OpenShift level; this needs to be addressed as it's available at the cloud provider level, like IBM Cloud.

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.

Setting up OpenShift locally can be challenging, particularly because it requires RHL Linux and has specific restrictions. Additionally, the documentation for local setups is lacking. Improving these aspects would make OpenShift more accessible to the community for trial and development purposes.

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.

It is actually very well laid out for a computer product. But maybe, since it has security built into it, it is sometimes very difficult for people to grasp.

It is much easier to work with Kubernetes than OpenShift. On the inside, all the security and other aspects are very much required by the container.

It has a difficult learning curve. Those are the areas where, from a customer perspective, OpenShift is a little challenging compared to other Kubernetes solutions.

The price must be improved.

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.

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.

I believe OpenShift Container Platform can improve in networking, architecture, and cloud areas by reducing deployment time, lowering costs, and streamlining engineer resources. Additionally, I would like to see more Azure I/O functions in the next release.

OpenShift Container Platform needs to work on integrations. 

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.

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.

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.

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.

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

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.

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. 

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.

The setup process is not great and could be better.

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

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.

Metrics monitoring feature needs improvement.

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.

One area for product improvement is the support limitations within the subscription models, particularly the restricted support hours for lower-tier subscriptions.

There is room for improvement with integration.

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.

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. 

The stability needs improvement. 

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.

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. 

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.

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 product's setup process could be easier. 

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

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

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.

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.

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 is an expensive solution, and its pricing could be improved.

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

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. 

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.

OpenShift Container Platform could improve by having better integration.