How Cloud Foundry, Kubernetes and OpenShift Can Be Compared

How Cloud Foundry, Kubernetes and OpenShift Can Be Compared? OpenShift and Cloud Foundry are cloud platforms. So they can be compared. We talked about Kubernetes here in the article What is the Relationship Between Microservices, Docker and Kubernetes, here in the article on Docker Vs Kubernetes Vs Apache Mesos, and here we have shown to Run Kubernetes Locally With Minikube. Kubernetes is different story. PaaS provides application orchestration. All of the tools and their integration is provided, so all that is required is the push of code and the platform will determine introspectively what we are attempting to execute, grab the requirements (buildpack), attach to any required services which are brokered through the platform, and setup all of the routing/proxies to get to your newly minted app. On the other hand, orchestration platforms (Mesos/Kubernetes/Swarm) require a Docker image as artifact. So, we need to take care of all of the application requirements, including how the apps/microservices will work together, how they will be exposed, and then instantiate them via an API.

How Cloud Foundry and OpenShift Can Be Compared

Older versions of OpenShift (when we have shown how to run WordPress on OpenShift) was a different thing than that of today. Kubernetes is a good implementation choice for the use cases where a user has specific requirements for tooling. However, the installation process can get a little complex. OpenShift is a bunch of extra features built around Kubernetes. OpenShift Origin will be better choice for scenarios where there is no existing tooling and the user needs to focus on his application code while using everything else available from an out-of-the-box set of tools present within the platform.

Cloud Foundry is a open source PaaS implementation. You can download Cloud Foundry and install your own PaaS to your own server. Cloud Foundry Foundation has existence beyond IBM, Dell, EMC, VMWare, Pivotal etc. Cloud Foundry has the benefit of being very structured and opinionated in its workflow and we can push apps and consume services. Their aim is to keep the developer experience focused on developing. Cloud Foundry also has the benefit of being multi-cloud. Pushing apps and consuming services is identical on AWS, GCP, VMware, OpenStack, etc. We could even run apps on IBM that consume Google Cloud services.

Puppet, Chef, Ansible, and Salt are configuration management and orchestration tools. Puppet like things can be used to set up a PaaS or SaaS. Cloud Foundry uses BOSH as configuration management tool. Cloud Foundry and OpenShift has similar capabilities in regards to their approach to the PaaS. OpenShift use cartridges, which include databases as well as languages and frameworks. Cloud Foundry have buildpacks. OpenShift is great for its gear idling. Cloud Foundry has good integrations with Pivotal’s big data and mobile services suites.

How Cloud Foundry and OpenShift Can Be Compared

As from the above discussion, we can see that although many new users confuse Cloud Foundry, Kubernetes and OpenShift, they are not same at least for the use-cases. OpenShift of today probably has limited, specific use-case as PaaS, while Cloud Foundry is widely used. Rest is Kubernetes and possibly we could clarify that Kubernetes is not exactly comparable.