NetApp is our storage provider and we have a product called Astra Control Center. We can back up and restore our containerized applications that are running on OpenShift. We use it to create a disaster recovery site for our business-critical containerized application.

Our second use case is for cloud bursting. When we have fewer resources available on-prem, we can move some of our non-critical applications to the cloud.

Our production environment can be run on AWS or any other cloud where we've deployed OpenShift, while we have our test and development environments on-prem. Once an application is certified, it can be moved from development to the production environment using Astra Control Center.

The CodeReady Workspaces reduce project onboarding time. With my experience, I was able to deploy the OpenShift cluster to make development ready in one day, with all kinds of related post-installation configurations.

And CodeReady Workspaces also reduce time to market. Red Hat OpenShift provides its OperatorHub from which you can find all the certified applications that are readily available on the portal itself. It gives you a cloud catalog-type feature directly on the OpenShift console. Through that, you get a GDP that is already certified, while deploying any kind of application. That means they are made to run with your OpenShift environment. You don't need to do any research to make it work with OpenShift.

OpenShift also provides us with the flexibility of cloud-native stacks while still making it possible to meet regulatory constraints.

The most valuable feature of OpenShift is the security context constraint (SCC). The solution’s security throughout the stack is good. And security context constraints provide port-level security. It's a granular level of control, where you can give privileges to certain users to work on certain applications. That's a great security feature.

The solution also provides a lot of security features on top of a regular Kubernetes cluster, which you can control. For example, in the namespace of OpenShift, there are different kinds of access levels. If you have a development team, you can provide limited access so that a developer can only deploy your application. If you're running any business-critical app, you can restrict the users' access to that app.

Also, Red Hat provides advanced multi-cluster management. You can manage multiple clouds with one solution, and I'm happy with that.

One area for improvement is the documentation. They need to make it a little bit more user-friendly.

Also, if you compare certain features and the installation process with Rancher, Rancher is simpler.

I have been using OpenShift for more than two years.

I have found some minor issues related to pod networking in which some of the OpenShift pods were not performing well. To resolve that, I needed to do a reinstallation of the cluster. Apart from that, OpenShift is pretty stable.

The scalability of OpenShift is good, but a competitor like VMware Tanzu can run more pods on the same system or the same hardware. So there's a little room for Red Hat to make it more scalable.

For us, OpenShift is an enterprise-level platform. We have about 10,000 users and we have plans to increase our usage.

The best part is the support from Red Hat. If you face any issues you can get great support.

As a partner, Red Hat is a nine out of 10 for helping us create the platform we need.

The installation is very good. There are a lot of options with which you can deploy OpenShift and you can deploy it on different environments. You can directly deploy it on a bare metal server, or if you already have a VMware-based infrastructure, you can deploy it there. That automation is very flexible.

The initial setup is straightforward, but for a first-time user, it might be a bit challenging because there are certain prerequisites that you need to follow. But if you follow the installation guide and you're able to do all the prerequisites, it's very straightforward. It takes less than an hour.

I used the Assisted Installer and did the IPI installation for OpenShift. I had all the infrastructure ready and deployed one cluster on bare metal. Then I deployed the OpenShift cluster on AWS.

For deployment and maintenance of OpenShift, a team of 10 should be fine. They can handle the installation and the post-installation operations for your day-to-day tasks.

I did it on my own.

I have tested VMware Tanzu but we didn't go with it because it comes in different flavors. If you want to use VMware Tanzu, for certain things, you need to buy another VMware product. For example, if you want to have pod services for your environment, you need to buy NSX. That's an extra overhead because you need a separate team that can manage NSX for you.

You need to follow the prerequisites for the environment and then proceed with the installation. There are different ways to do the deployment but you should do it the way that is most comfortable for you.

You can also deploy OpenShift using Ansible. If you want to automate the entire process of your OpenShift installation, including the server, network, and storage, you can opt for Ansible. That way, you will have end-to-end automation for your entire stack as well as OpenShift. That is good flexibility.

The biggest lesson I have learned from using OpenShift is that you can go with bare metal and you don't need to pay extra for the VMware Hypervisor. In terms of installation or manageability, it's simple. You just need to follow some guidelines and you will be good.

We're going to deploy the entire core banking of the bank on the platform.

It helps us through consolidation, ease of use, portability, and because I can use microservices. It's like a one-stop shop for most of my containerized applications that are going to be deployed.

The most valuable features are that

• it's cloud agnostic
• the containerization and security features are outstanding.

The cloud-agnostic aspect means I can move to AWS, Google, or Azure. That means it is not a limitation. It gives me flexibility.

For running business-critical applications, on a scale of one to five, where five is the best, OpenShift is 4.8.

Room for improvement is around the offerings that come as a bundle with the container platform. The packaging of the platform should be done such that customers do not have to purchase additional licenses.

They should partner with Jenkins. It goes without saying that I need Jenkins for my CICD. If Jenkins comes with support, that's good. But if there is a licensed product, I need to secure that license and then I will get support.

Although the bundling with OCP is better than that offered by others, they can work more on it.

We implemented OpenShift in January 2023, so about six months ago, but we have not fully used it. It's the first time that we've installed it, and we're yet to implement.

It's pretty scalable because of the architecture. I don't see any issues in terms of scaling up or across. During our design phase, we had to scale across and as far as the design was concerned, it was pretty easy.

We can also scale it back. We can reduce or expand as per our needs.

In the future, it will be used by our entire bank, with between 8,000 and 10,000 users.

We intend to expand the usage but we have to wash our hands of the core banking system first, which itself is a huge system. Once we're done with that, we'll think about other applications.

The forums and services are perfect. Excellent.

We did not have a previous container platform solution. We did try to build our own but it failed, badly. Building a container platform is not an easy task.

The initial setup is in between straightforward and complex. It's not so easy but not that tough. But we do require a lot of training.

Our deployment took one month.

Red Hat did most of it. We just provided them with the bare metal and away they went. It was a very time-bound project, and the Red Hat team was there. Our teams also worked with them. It was a collaborative exercise. On our side, there were 10 to 15 people involved, but there were five key people.

The CodeReady Workspaces should help reduce time to market if I use the CICD pipelines. That's what we aim for, and that's what the container platform is built for. That's something that goes without saying.

We're using Red Hat Linux across the bank for servers. We will use quite a number of Red Hat products during our core banking deployment, including AMQ, Process Automation Manager, and a couple of other products that are bundled with OCP.

The integration is something that is out of the stack. It's more of a middleware conversation and the middleware for us is an IPaaS. It's less about the stack and more about the application. I don't think there are any issues communicating via APIs. And the access management is pretty adequate. I can plug in any IM or document archival solutions. It's pretty easy to integrate.

Red Hat, as a vendor, has shared ample information with us to help us make decisions. That is where a partner comes into play and we're pretty happy with Red Hat.