OpenShift Container Platform pros and cons

The stack in the software supply chain is one of the main reasons that we use OpenShift. When I came to this company, we bought hardware from IBM named Bluemix, and they used ICP, which stands for IBM Cloud Private.

Some of the primary features we leverage in the platform have to do with how we manage the cluster configurations, the properties, and the auto-scalability. These are the features that definitely provide value in terms of reducing overhead for the developers.

The auto scalability feature, which is based on smart agendas, determined from pre-prepared rules is the most valuable feature. You can also create different routes for deployment. Deployment types can be provided with an identifier, such as an ARB deployment. This really helped in rolling out releases without disrupting services for the end-users.

The console or the GUI of OpenShift is awesome. You can do a lot of things from there. You can perform administration tasks as well as development tasks.

The solution's security throughout the stack and the software supply chain is very reliable. When it was on-prem, it was by default secured by our company firewalls and security tools, and now it's in the cloud, which has its security and systems in place. This provides stability to our infrastructure.

The software is user-friendly and straightforward to use, which is favorable to a developer.

The most valuable feature of this solution is its scalability on demand, which allows for potentially lower costs, and Built-in resiliency.

On OpenShift, it's easy to scale applications. We can easily scale up or scale down.

The product is stable, reliable, and easy to use, from a well-known company, has a large volume handling capacity, and more and more organizations are moving to OpenShift.

Centralized control of container resources is most valuable.

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.

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.

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.

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.

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.

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 copy/pasted to other applications in the development process.

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.

The initial setup can be hard.

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

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.