At first glance, you would think that there is a lot of overlap between Kubernetes and Cloud Foundry. Both have been built to “deploy, scale, and manage applications deployed into containers.” If they both manage container applications, what’s going on? Why was Kubernetes created? What is the difference? Similarities? Which is better? Do they overlap? Can they be used together? What comes next and what is IBM doing to help that happen?
There are some important questions to answer, so let’s go through them:
Why was Cloud Foundry created? Cloud Foundry was created with the mission of delivering applications to the cloud quickly, easily, and with the full capabilities of mature “cloud-native” hosting, such as seamless building, rapid deployment, flexible scaling, and important service integration. Created and deployed as containers, applications operate smoothly with cloud-native application development. Applications are stateless, making them dramatically easier to scale, operate, and manage. Applications of this nature are often referred to as 12-factor apps.
Why was Kubernetes created? Open-sourced by Google in 2014, Kubernetes focuses on orchestrating containers by providing primitives such as pods, nodes, statefulsets, replicasets, and deployments. Kubernetes has been described by its founders as a platform for platforms, used to create other delivery platforms, and it is increasingly important for enterprises as they embrace hybrid cloud strategies.
What are the similarities and differences? Both Cloud Foundry and Kubernetes are open source systems with large, healthy ecosystems and passionate users. Kubernetes provides a flexible system and is operator-focused, but it adds complexity in running simple and stateless applications. Cloud Foundry provides a higher-level, developer-focused user experience. The two platforms have overlapping uses, but very different sweet-spots. Kubernetes excels at operating complex, distributed systems, while Cloud Foundry can be significantly simpler and more effective for deploying and managing 12-factor applications. Cloud Foundry explicitly separates the roles of platform operators and developers, with a focus on enhancing developer productivity. More importantly, Cloud Foundry is built as a multi-tenant system, whereas Kubernetes is not currently recommended in multi-tenant contexts. This allows small teams to maintain and provide a single Cloud Foundry cluster for a large number of users.
Which is “better”? The question about “better” really depends on the audience. Is peanut butter or jelly better? It’s not about better, it’s that the target audiences for Kubernetes and Cloud Foundry are different.
Companies building cloud-native applications tend to have users with distinct roles—developers and operators. More often than not, these roles tend to fall in different departments. Both need and use different tools to get their jobs done. Developers are responsible for high-throughput application design and development (not platform and cluster management), so they need a rapid developer experience. Operators are responsible for deploying and ensuring the high-availability and resiliency of applications, and they need a flexible platform that allows complex deployments to satisfy HA, DR, and isolation constraints.
Maybe we should take a page from @kelseyhightower, who advocates for Kubernetes at Google: