Compare Red Hat OpenShift vs. Cloud Foundry in a Kubernetes faceoff
Looking for a container ecosystem platform? OpenShift and Cloud Foundry have similar roots as PaaS platforms, but this comparison identifies a clear winner for most organizations.
In the ever-changing, complex world of containers and container ecosystems, organizations might compare Red Hat OpenShift to VMware Cloud Foundry, but they are dissimilar products that can accomplish similar things.
An OpenShift vs. Cloud Foundry comparison must account for the fact that these container ecosystem platforms share a lineage but have slightly divergent goals. Cloud Foundry, historically a PaaS offering, has expanded to facilitate open container development, and supports deployment. OpenShift has evolved as a container orchestration and Kubernetes ecosystem platform that only recently started to provide a development model. We’ll get to why this product lineage matters in a moment.
To further complicate matters, the most common enterprise Cloud Foundry seller, Pivotal, was acquired by VMware in 2019, and VMware’s Tanzu suite competes with both Cloud Foundry and OpenShift.
PaaS vs. container ecosystems
Both OpenShift and Cloud Foundry emerged when the cloud meant a provider delivers infrastructure, a platform or software as a service. Both also embraced an open source approach and used container technology as a convenient way to deploy their PaaS-based applications — but from there the companies diverged.
Cloud Foundry is an open source cloud application platform, with containers and container technology as pieces of a much larger and comprehensive suite. Think of Cloud Foundry as a complete development and deployment environment, with applications tied to the PaaS framework it defines. Users can host Cloud Foundry anywhere. The platform had its own orchestrator, Diego, which it eventually abandoned in favor of industry-standard Kubernetes.
Red Hat also had a proprietary orchestrator, GearD, but joined the Kubernetes religion and shifted its OpenShift strategy to be a generalized platform to deploy all enterprise applications through containers and Kubernetes. Red Hat OpenShift is less about development than an ecosystem for any application model: stateful or stateless, new or old, in the cloud or in a data center. OpenShift is no longer a true PaaS — it defines capabilities, not programming models.
This introduction is critical to our OpenShift vs. Cloud Foundry faceoff, because there are two ways you can look at these contenders: as a PaaS, which is what both used to be, or as a Kubernetes or container ecosystem product, which they essentially are now. Let’s dispose of the PaaS mission. Unless your business is confined to a narrow range of applications and models for application development, and can achieve them with internal development or with software from the Cloud Foundry community, you should not consider a PaaS model. Nearly all enterprises run a mixture of software written to a spectrum of development models and tools, so a single PaaS is the wrong answer.
That leaves the container ecosystem mission, which both companies essentially support. Containerization has converged on Kubernetes orchestration as the universal management centerpiece. Red Hat was among the first to recognize and get on board with the emergence of the container ecosystem, and enhance OpenShift’s inventory of software elements. Cloud Foundry recently joined the Kubernetes community.
The best positioning with Kubernetes ultimately determines the outcome of this OpenShift vs. Cloud Foundry comparison. Let’s take a look at some core differences between the platforms.
At the architectural level, Cloud Foundry is still a PaaS, which means that organizations might be forced to adopt the proprietary model of application development that the platform presents. The software components are tightly integrated with the tools, right down to the deployment level. Cloud Foundry software is also far less portable than non-PaaS options because it’s a proprietary framework. Since Kubernetes is now the Cloud Foundry orchestration framework, you can deploy containerized applications from any source through Kubernetes, but they’re Kubernetes applications and not Cloud Foundry ones.
Red Hat OpenShift is, in a sense, an integrated set of tools around the application. You don’t write to OpenShift; instead, developers write an application and then deploy it through OpenShift. Anything that can run in a container can deploy with OpenShift. Some tools, such as the Istio service mesh, might require accommodations in application design and development, but these tools are all open and widely used so there is no lock-in. The entire OpenShift ecosystem is designed to meet a common goal of a complete Kubernetes environment using open source tools and architectural models.
Enterprises are not moving everything to the cloud. Further, most enterprise applications can’t or shouldn’t move information between the cloud and data center, or run split across the cloud and data center. The biggest value of containers and Kubernetes to enterprises is its universal model — it enables applications to run across any cloud or dedicated resources in the same way — but that depends on the integration of tools outside Kubernetes itself. This integration is a key part of the comparison between Cloud Foundry and OpenShift.
Anything that can run in a container can deploy with OpenShift.
Cloud Foundry supports Kubernetes and tools associated with Kubernetes for monitoring and management, hybrid and multi-cloud, and service mesh and service workflow management. However, these tools are not automatically integrated into Cloud Foundry deployments, and users therefore must do integration heavy lifting. Cloud Foundry’s native PaaS-based elements are stateless, so users must also harmonize them with the largely stateful data center applications deployed with Kubernetes.
OpenShift is a Kubernetes ecosystem that includes everything a user likely wants for container deployment, monitoring and management, service discovery and security, and workflow management. Users might tweak these tools for actual deployment and use, but the vendor pre-integrates them and documents how they work together. Applications that work within the OpenShift ecosystem are easier to integrate with each other, and since that ecosystem can embrace virtually any application, the overall level of integration difficulty is lower.
Front-end app development
Enterprises integrate public cloud and data center components within the same application for many purposes. They often develop the cloud-native front-end portion of the application separately from the rest of the company’s software development processes. There’s considerable interest in low-code or no-code development for this front-end portion of business applications. Organizations considering OpenShift and Cloud Foundry should evaluate how the platforms compare for front-end cloud-native app development.
The Cloud Foundry PaaS approach presumes stateless deployment, and since stateless is the best model for cloud-native application front-end deployment, it offers specific platform support to develop these applications. Its infrastructure virtualization harmonizes deployment across the public cloud and data center resources, which makes Cloud Foundry application components highly portable across hosting environments.
On the downside, Cloud Foundry on public clouds has a large resource footprint and complex deployment. If users deviate from Cloud Foundry’s PaaS framework to adopt a different serverless or stateless development approach, they must manage it around the main Cloud Foundry PaaS on Kubernetes. Additionally, Cloud Foundry only supports one major low-code/no-code framework, Mendix.
OpenShift has no specific support for front-end cloud development, but it does not restrict users’ choice of development model or platform tools. OpenShift’s low-code/no-code agnosticism means users can pick from any of the tools in this space. A platform should not dictate programming practices or create non-portable code.
Vendor outlook and evolution
Pivotal, which provided most of Cloud Foundry’s development support, was acquired by VMware, a move that likely will result in a significant staff reduction. The Cloud Foundry Foundation continues to support the product, but some question Cloud Foundry’s future. The fate of Cloud Foundry rests on VMware, and whether the company incorporates it into the vSphere model, which is also a kind of PaaS.
IBM, which has acquired Red Hat, has a popular BlueMix software framework that also includes Cloud Foundry. Red Hat is the largest open source software provider, and its OpenShift model is built from community-supported tools with a broad developer base. While there is some uncertainty about how IBM will integrate Red Hat into its sales efforts, the IT giant has ample resources to support OpenShift, which remains its flagship of next-gen software.
And the winner is …
It’s rare that a technology comparison is so decisive, but in this OpenShift vs. Cloud Foundry battle, OpenShift is the clear winner. Cloud Foundry’s large user base would be wise to watch whether VMware continues Pivotal’s leadership of Cloud Foundry, if another player picks up the mantle, or whether Cloud Foundry survives as an open source project without a key corporate sponsor. Once they know, they can decide whether to stay with the platform or move on.