I work with all the Kubernetes platforms depending on the project. I might use OpenShift, Rancher, or even Q&E depending on the needs of the project. 

I previously used Kubernetes from Canonical. Everything in OpenShift is more secure out-of-the-box. If we take a Kubernetes installation like the one from Canonical, everything is open, nothing is secure. We require a security person to look at the cluster and create secure settings. On the other hand, we have all the advantages of having Kubernetes because we get all the new features the day they are out, and Canonical is really responsive to having the newest Kubernetes as soon as it's out. 

The integration with VMware is not nonexistent, but not as good as OpenShift, in how we roll out. I have not used Kubernetes in three years but at that time, everything was done by hand. It lacked an integrated installer, unlike OpenShift.

We also use Tanzu, which has more limitations. If I have to use an F5 load balancer or other third-party products, Tanzu shrinks a little bit. It is not as mature as Red Hat OpenShift, which is more open to other products. I have an F5 load balancer, and I struggle a bit to integrate the F5 load balancer with Tanzu, whereas with OpenShift, it happens directly. For Tanzu, I have to have another layer on my load balancer, which is Avi. I have to use their services. Adding one more product into the environment brings some complexity, whereas OpenShift is very agile in nature. It adapts to all kinds of products that are not part of the same stack. So, I had no issues with that. I would rate OpenShift higher than Tanzu because OpenShift is a much more mature product.

We were using Kubernetes. We switched to OpenShift because we wanted an enterprise-level usage tool. So, we needed a more stable product.

We chose OpenShift mainly because we get good vendor support. In case of any issues, we can easily collaborate with the vendor to get a proper solution. From the operations perspective also, OpenShift is good. That's also the main reason why it's being used here.

We previously used an on-premise server and implemented a massive change by moving from on-prem to AWS cloud provider to OpenShift.

Previously, all we used were standalone Unix machines. We didn't use a different container orchestration, like Mesos. We never considered building our own. We took a look at OpenShift a long time ago and it was really the best at the time.

We previously worked with Kubernetes cluster, but we switched to using OpenShift, as advised by our architect. This change is aimed at achieving greater scalability and stability for our product, as we've encountered challenges with our setup at the time.

I didn't use it, but my company used the PKS solution.

I'm not sure because I wasn't involved in the installation. 

We never considered building our own container platform. I've only seen customers using Vanilla Kubernetes because OpenShift is a little bit expensive, and some specific organizations have chosen to invest in a strong team because they would need a strong team to build Vanilla Kubernetes. They are succeeding in maintaining that way of working. I have seen this a couple of times.

Previously, I had experience with VMware's Kubernetes version. VMware was very difficult to install. I could not understand the route they were taking and why there were so many steps. 

AWS and DigitalOcean are products with which I have some experience.

Kubernetes on AWS is a bit complex to set up, whereas OpenShift is easier for me to set up. However, they use the same things during the setup process. OpenShift is just a better product for a new user compared to AWS since the former is easier to understand.

Initially, we used to run Vanilla Kubernetes, which is open source. Then, we realized we were short on skill sets. Another organization had done a PoC of Red Hat OpenShift, and it passed. So, our organization was gracious enough to allow us to spend money on Red Hat OpenShift licenses. That was in 2019.

With Vanilla Kubernetes, we were not able to successfully implement service mesh. That comes already preconfigured for you with Red Hat OpenShift. 

In terms of traffic routing and firewall management, it was a nightmare managing that in Vanilla Kubernetes. However, with Red Hat OpenShift, you only add specific IPs in firewalls, as opposed to the nightmare that we used to see with Vanilla Kubernetes.

Red Hat's commitment to open source is one of the reasons that we went with it. We knew that we would get continuous updates. Also, the option of keeping our OpenShift cluster up-to-date with new services was a headache that we passed onto Red Hat. 

We previously used a different solution. We switched to this product since it was more flexible.

We have considered building our own container platform as well since we needed something on-prem. However, OpenShift already provided what we needed, and so it wasn't necessary. 

I'm not sure if we also use any other Red Hat products. 

We evaluated Docker before moving to OpenShift.

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.

We were using individual Tomcat on VMS for a high availability and scalable architecture.

I have not used any other container orchestration platform, except Kubernetes, which is the base platform for OpenShift.

Before OpenShift we were only using Docker. There was no Kubernetes in our infrastructure. With Docker, there is no scalability. It is just a package. In terms of scalability and availability, Docker will fail. That is why we chose OpenShift as a platform.

We did not use a previous solution.

Based on Kubernetes vanilla, or Rancher or other PaaS, security is quite heavy to integrate with RBAC, network policies or namespaces isolation.

With Openshift Origin or Enterprise we avoid security management which is managed automatically at namespace level.

As a consultant, I have no installed OpenShift for my own solutions. But I have worked with Openshift and Cloud Foundry. Both are excellent products. But some of the limitations inherent in Cloud Foundry made it unfeasible for several of my clients.

OpenShift has been running for the past three years, since the project started. We were developing the project's architecture, trying different solutions. In the end, we chose OpenShift as a well-known and intensively developed software, with many really useful features.

I prefer Kubernetes. But customers need very good support from developers, which Kubernetes do not have.

I started using another technology, whose name I don't recall. The goal of OpenShift is to make things easier by connecting all tools in one switch.

We were using VMware which is more expensive for no good reason. Thank you OpenShift.

We have not switched from another product. We also support other cloud offerings like Kubernetes.

Yes, we used IBM SoftLayer and we were not happy with it. Another solution that we are using is AWS, and we are pretty happy with it.

We previously used IBM WebSphere.