Red Hat OpenShift and Pivotal Cloud Foundry are two standard implementations of a Platform-as-a-Service. Even though there are quite a few similarities between the two, an objective comparison is hard to find. Now there might be sound reasoning behind that, but as these platforms are essentially open, such a comparison should be possible.
This article presents a list of features of both platforms and details the differences between the implementation of these features. It is intended to be short and concise. It is not intended as a buying guide: an implementation requires more than just a checklist! And even though I am tempted to write a short paragraph detailing “which one is better” with every feature described, I am not going to – it is simply not possible without knowing the implementation context, and I am trying to be as objective as possible.
In their own words
The websites of Red Hat and Pivotal describe their products as follows:
“Red Hat OpenShift Enterprise is a container application platform that brings docker and Kubernetes to the enterprise. OpenShift Origin is a distribution of Kubernetes optimized for continuous application development and multi-tenant deployment. OpenShift adds developer and operations-centric tools on top of Kubernetes to enable rapid application development, easy deployment and scaling, and long-term lifecycle maintenance for small and large teams.” OpenShift.io is an open online development environment for planning, creating and deploying hybrid cloud services.”
“Pivotal Cloud Foundry is the proven solution for companies seeking software-led, digital transformation. Cloud Foundry is an open platform as a service (PaaS) that provides a choice of clouds, developer frameworks, and application services. Cloud Foundry makes it faster and easier to build, test, deploy, and scale applications. Cloud Foundry BOSH is an open source tool chain for release engineering, deployment and lifecycle management of large scale distributed services.”
I guess the difference between the two is pretty obvious as far as the enterprise version is concerned: Red Hat has a technology-focused marketing machine, aiming its platform at developers and technology-savvy people. Pivotal uses a different rhetorical strategy, focusing instead on change and digital transformation. For the open source versions, the message is pretty similar.
I find it quite interesting that open source technology champion Red Hat does not prominently feature the fact that OpenShift is open source in its marketing messages, whereas Pivotal (of which its parents and siblings Dell, EMC and VMWare are effectively closed source) does. On the other hand, Red Hat specifically mentions the fact that OpenShift enables rapid application development, even though one of the more popular of such development environments – Mendix – is often hosted on Cloud Foundry.
Some of the features above are pretty obvious, but others do warrant some explanation. These are numbered in the table below and will be explained in the remainder of the article.
Disclaimer: compiling this table was a task performed by a human. Humans make mistakes.
1 Architecture
The architecture of OpenShift is compound, whereas Cloud Foundry is proprietary – but both are largely modular. This means that both platforms consist of several components that work together to offer the combined functionality of the PaaS. However, Red Hat uses primarily existing open source products for the core functionality (such as Kubernetes and EFK), even though it does use a set of specifically developed OpenShift components. The core components of Cloud Foundry are largely proprietary products (such as Diego and Garden), even though a recent switch to Kubernetes does add some external open source components to the mix.
2 Container and orchestration support
Both OpenShift and Cloud Foundry support Docker and Kubernetes. Red Hat made the shift to the container engine and orchestration layer in 2016 – a lot earlier than Cloud Foundry, which announced official support during 2017. In practice, this means users of Cloud Foundry have two options and even though Pivotal ensures that Diego, the previous container orchestration layer, is not going anywhere – the default orchestration layer is now Kubernetes based. It does show that Kubernetes is gaining traction as the container orchestrator of choice.
3 Container Operating System
Red Hat offers its own container optimized operating system with Atomic, even though it is possible to run any operating system in its containers (including of course RHEL).
4 Underlying Infrastructure
Cloud Foundry prefers a virtualization layer for running its platform on, which comes as no surprise considering its relation to VMWare. It is possible, however, to run on bare metal when using RackHD – which is part of EMC, another close relation. But even though Red Hat offers its own virtualization engine and platform (RHEV), deploying Open Shift on bare metal is one of the preferred scenarios.
Other than that, both platforms support a similar range of cloud providers, primarily Azure, Google Cloud and Amazon (public) and OpenStack (private).
5 Minimum AWS install
Amazon has instructions available on how to deploy both Cloud Foundry and OpenShift on its infrastructure. The minimal viable install for both platforms is described below. I am focusing on the instances only, of course a full install requires other components such as load balancers (both 3) and S3 buckets (both 5) as well.
OpenShift requires 3 masters, 3 etcd and 3 nodes, all of type m4.xlarge. This leads to 9 instances. Cloud Foundry is quite a bit more demanding – in number of VMs that is, requiring 1 t2.medium NAT instance, 1 m4.large Ops Manager, 1 t2.micro Bootstrap instance, 1 m4.large BOSH instance and for a starter deployment it requires another 19 instances containing the Cloud Foundry Elastic Runtime, spread out over 12 t2.micro, 3 r4.xlarge, 2 m4.large and 1 t2.small. This leads to 22 instances, which increases to 40 when deploying a multi-availability zone install.
Even though pricing the solution this way is quite dangerous, here goes: this leads to $1,8 per hour for OpenShift and $1,4 per hour for Cloud Foundry (pricing is on demand, general purpose, current generation Linux, US East at https://aws.amazon.com/ec2/pricing/on-demand/). As said, this is only for the VMs, without storage – no further garantuees!
The instructions are available at http://s3.amazonaws.com/quickstart-reference/redhat/openshift/latest/doc/red-hat-openshift-on-the-aws-cloud.pdf andhttps://s3.amazonaws.com/quickstart-reference/pivotal/cloudfoundry/latest/doc/pivotal-cloud-foundry-on-the-aws-cloud.pdf.
6 Public cloud and trial
Both Cloud Foundry and OpenShift have a public cloud based offering with free versions available. The Red Hat public version offers 1 project with 1Gb memory and 1Gb storage for free, with pro prices starting at $50 per month (10 projects, 2Gb-48Gb memory and 2Gb-150Gb storage). Cloud Foundry uses different pricing: the pro version comes at $0.03 per Gb per hour, whereas the free version offers 2Gb of memory and $87 of free credit. The Cloud Foundry free version expires after one year, but OpenShift stays available.
7 Community
Both Cloud Foundry and OpenShift have community versions available on GitHub. A community deploy of Cloud Foundry is best done through its command line client Bosh. The community version of OpenShift is an upstream project, which means that new (experimental) features end up in this version before maturing in the enterprise release.
8 Minimal
Both Cloud Foundry and OpenShift offer a minimal, developer oriented version of their platform: PCF Dev (https://github.com/pivotal-cf/pcfdev) for Cloud Foundry and MiniShift (https://github.com/minishift/minishift) for OpenShift.
9 Certified platforms
Cloud Foundry allows its technology to be used in certified platforms, of which a number exist. The best known one probably is IBM’s BlueMix, which to be fair is more than just Cloud Foundry – it incorporates the Cloud Foundry technology in its own Platform-as-a-Service. A list is available on https://www.cloudfoundry.org/certified-platforms/.
10 Service Registry and Discovery
For Service Registry, Cloud Foundry uses Consul and OpenShift uses its own tooling – but with similar functionality. With Service Discovery, there is a larger difference: Cloud Foundry uses Eureka, a common open source tool. OpenShift uses multicast to make services known.
For more information, see this article https://blog.openshift.com/service-discovery-openshift-using-multicast/.
11 Source Code repository
Deploying applications with Source-To-Image currently requires using a git repository, even though OpenShift can be configured to use other source code repositories (such as Subversion) as well. With Cloud Foundry, it does not matter what repository is used.
12 Graphical User Interface
Both OpenShift and Cloud Foundry have a built-in, native user interface, even though the Cloud Foundry interface (Ops Manager) is meant for deploying and managing a full production environment. There are several community initiatives to produce an additional (management) interface for Cloud Foundry however, with SuSE (which took over Cloud Foundry components from Hewlett Packard) leading a serious attempt with Stratos. More information available at https://github.com/SUSE/stratos.
13 Filesystems
The difference in supported filesystems between Cloud Foundry and OpenShift has to do with the container implementation of both platforms. The longer list in OpenShift is the result of its Docker implementation.
14 Database
Cloud Foundry requires a relational database as part of its platform install, typically MySQL. OpenShift uses CoreOS’s etcd, a distributed key-value store as its configuration store. Some of the tools used as part of OpenShift deploy a database as well, such as a Cassandra instance for Hawkular.
15 Autoscale
OpenShift does support automatic scaling of containers (through Kubernetes) natively, whereas Cloud Foundry does not – but it is able to enable this functionality through an extension currently in its incubator program. More information available at https://github.com/cloudfoundry-incubator/app-autoscaler
16 Deploy
Applications in Cloud Foundry are pushed to their resulting environment, whereas applications in OpenShift are pulled from a git repository before they are deployed in containers. The difference is arbitrary, but even though both platforms support automated application deployment and integration with Jenkins, OpenShift offers a more complete implementation out of the box. Pivotal does offer its own tool to create and run development pipelines called Concourse, which integrates nicely with Cloud Foundry (more information at https://concourse.ci). Something similar is available from Red Hat, in the form of Fabric8 (https://fabric8.io) – even though this tool focuses more on the full development experience of microservices.
17 Zero downtime deployments
OpenShift uses Kubernetes to enable zero downtime deployments, which basically means a new version of an application can be deployed without the application going down. Cloud Foundry does not support this out of the box, but uses blue-green deployment – which basically means two identical versions of an application are run in two production environments, one of which is live. When it is time to update, the application is rolled out to the production environment which is not live and after successful testing, the two environments are switched. Of course, data consistency is something to take into close account with such a strategy. For more information, see https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html. Next to this, zero downtime deployment is possible with the Autopilot plugin.
18 Statefull and stateless
Even though a PaaS – and particularly a container platform – works best when adhering to the Twelve-factor app standard (https://12factor.net/), specifically the factor about stateless processes (https://12factor.net/processes), it is possible to run statefull applications on OpenShift. Why you would want to do this apart from a proof-of-concept is beyond me, though. For more information see this excellent article on Kubernetes and statefull at https://blog.openshift.com/kubernetes-state-storage/.
19 Build mechanism
The build mechanism is where Cloud Foundry and OpenShift differ greatly. OpenShift uses a method called Source-To-Image (S2I), which builds Docker images from source code stored in a git repository (which in turn hides the use of Dockerfiles or Docker build from developers). This separates the build process from the resulting image. From a very high-level perspective, the build process creates a builder image which builds or compiles the code, which is then deployed to a final image. This way, the resulting images are kept as small as possible.
With Cloud Foundry, the focus is on the resulting application. It comes with a set of system buildpacks (initially created by Heroku), which are used to compile (or publish) a large set of common languages (such as Java, .NET and Python). When an app is pushed, Cloud Foundry examines the app and decides which buildpack to use when configuring it. Essentially, a buildpack is a set of scripts which when run result in self-contained app, including for example downloading dependencies. Buildpacks is possibly the more flexible approach, whereas Source-To-Image results in more portable applications.
20 Layers
Another difference between Cloud Foundry and OpenShift is the internal organization of container images. Images in Cloud Foundry only have two layers: one for the root operating system and one for the application with all its dependencies (and data). Because OpenShift uses Docker, the resulting images have several layers, which are then combined. Each layer represents a single command in a Dockerfile, the script which produces Docker images. If deploying an application in a container takes four steps, the resulting image will have four layers. Just like with Cloud Foundry, only the last layer is writable.
A more in-depth comparison is available at https://www.cloudfoundry.org/cloud-foundry-containers-difference-warden-docker-garden/.
21 Command line
Just a small difference here: Cloud Foundry has two command line tools, Bosh (used to administer the platform) and CF (used to deploy applications). With OpenShift, these operations are combined in one single tool: OC.