CloudFoundry and Kubernetes are two open-source technologies used to run applications in the cloud. Selecting the right platform for your deployments is an important choice to maximize performance, maintainability, and the productivity of your developers.
In this article we’ll compare the characteristics of both CloudFoundry and Kubernetes. Whether you’re already using one of the pair, you’re trying to make the choice for your next project, or you’re just curious to learn how they differ, we’ll explore their capabilities and explain their use cases.
Defining the Platforms
CloudFoundry is billed as a development platform for cloud-native applications. Kubernetes provides production-grade container orchestration. Both are used to deploy applications into cloud environments but they each approach this aim from a different direction.
CloudFoundry is a full Platform-as-a-Service (PaaS). It provides a fully automated development experience that’s founded on the buildpack model. When you use CloudFoundry’s CLI to cf push (deploy) your app, the service detects the programming languages, frameworks, and supporting technologies you use. It automatically provisions the correct cloud infrastructure to serve your project.
Kubernetes is not regarded as a fully-fledged PaaS. It’s focused on container orchestration, the practice of scaling and distributing container instances across multiple physical nodes. Deploying to Kubernetes is a more hands-on approach where you define the infrastructure your containers need.
CloudFoundry is aware of your application’s internals: it extracts meaningful information about your project’s workings, then uses that to automatically assemble infrastructure components with minimal mandatory guidance. By contrast Kubernetes is a generic framework for deploying containers. It lacks any inherent awareness of your application’s requirements; the shift in vocabulary from “applications” to “containers” illustrates how Kubernetes works with smaller units that you combine to create complete systems.
Advantages of CloudFoundry
CloudFoundry gives you an application deployment platform that runs on any major cloud. Kubernetes offers a similar platform-like model but it’s focused on containerized workloads. CloudFoundry adds value by giving you built-in functionality at the application-level, reducing the work you need to do when wiring components together.
Capabilities like traffic routing, load balancing, and DNS are integrated into your deployments and configured via the CloudFoundry CLI or a simple config file in your repository. With Kubernetes you need to manually add components such as Services and Ingresses to route traffic to your containers, effectively assembling a network stack from scratch.
A CloudFoundry installation provides a marketplace of services that are ready to add to your application. These range from databases and message queues to API gateways and integrations with third-party platforms. This makes it quick and easy to extend your stack with external components. Kubernetes doesn’t have anything comparable; each component needs to be packaged as a container and manually added to your cluster.
CloudFoundry includes other convenience features for authentication and user management. Kubernetes doesn’t compare in this area either: apps need to implement their own authentication mechanisms and you’re responsible for securing your cluster using tokens and RBAC rules.
Advantages of Kubernetes
Where Kubernetes excels is when it comes to adaptable scaling and replication. Pods of containers are easily distributed across physical nodes without impacting network connectivity or relationships to other services. CloudFoundry has scaling too but the emphasis on application management means it’s less granular and not so ideal for rapid load-driven auto-scaling of specific components (although this is possible with the auto-scaler module.)
Kubernetes has the benefit of an active open-source community that’s continually expanding and building adjacent products. Interest in Kubernetes has grown rapidly over the past few years, a trend that’s not been shared by CloudFoundry. The generic approach taken by Kubernetes makes it a more broadly applicable technology, in turn encouraging its adoption. You’ll find it easier to hire skilled Kubernetes engineers as there are more of them out there.
Kubernetes has an extensible architecture where you bring exactly what you need. You’re free to replace components in your Kubernetes distribution and add new fundamental resource types for use in your deployments. This keeps you in control of your application’s architecture and leaves your infrastructure accessible and open to change.
CloudFoundry is a highly opinionated solution that does most of the hard work for you; this accelerates initial deployment but gives you less opportunity to replace components, add overrides, and evolve your strategy over time. Once you’ve chosen CloudFoundry, you need to settle in to its way of working to continue to realize its benefits. Kubernetes places fewer restrictions on what your infrastructure looks like. It can be readily adapted to suit highly specialized environments.
Deployment Models
You can see the application vs container model in practice by looking at how deployments actually work in the two different platforms. Here’s an equivalent basic deployment made first to CloudFoundry and then Kubernetes.
CloudFoundry
With CloudFoundry you install the cf CLI, head to your working directory, and run the following command:
This will build and deploy your project using the CloudFoundry instance your CLI is authenticated to. The application will be named my-app. CloudFoundry will detect your source code type, acquire the appropriate buildpacks, build your application, and launch it into your cloud infrastructure.
Deployments are configured with a simple YAML file called manifest.yml:
Running cf push against a directory with this manifest would deploy four replicas of your app. The EXAMPLE_VARIABLE variable will be accessible from your source code.
Kubernetes
As Kubernetes works with containers, you need an image for your app before you can get started. You’ll have to write a Dockerfile and use docker build to build it:
Once you’ve got your image, you can write a set of Kubernetes manifests that describe the objects to create in your cluster:
This manifest creates a deployment of the my-app:latest container image that will run four replicas concurrently. It also sets the EXAMPLE_VARIABLE environment variable, making it available within the running containers.
Now you can use Kubectl, the Kubernetes CLI, to launch your container instances into your connected cluster:
These two minimal deployment examples illustrate the differences in concept, workflow, and developer experience between the two technologies. CloudFoundry’s automated build procedures result in a friction-less deployment experience that’s easily configured with CLI flags or a simple YAML file.
Kubernetes tasks you with building your application’s components into container images, then defining how they should run in your cluster. You need much more upfront configuration which is partly responsible for Kubernetes’ reputation of being complex and challenging to learn. Persevering rewards you with the ability to exactly craft your infrastructure around your application; with CloudFoundry, you can end up adapting your app to work within the constraints of the platform.
Using Both Platforms
The two technologies don’t exist in completely separate silos. It’s possible to run CloudFoundry on Kubernetes, a model where the platform launches workloads into the Kubernetes cluster it is itself deployed to.
In Kubernetes containers are the basic unit. This creates an expectation that you’ll accept responsibility for building and supplying container images for your workloads. CloudFoundry’s application-level model is a higher concept which layers in additional abstractions to build and prepare deployments for you. These are two distinct strategies that can both add value to the development experience depending on what you’re creating.
Combining the technologies can be a viable approach that lets you access the unique advantages of them both. You can use CloudFoundry for straightforward applications that work with standardized infrastructure. Projects which require a more bespoke system could be deployed straight to the underlying Kubernetes cluster, unlocking the flexibility of self-managed infrastructure.
Conclusion
CloudFoundry and Kubernetes are two cloud-native platforms vying for the attention of developers and operations teams. Which you should choose depends on the app you’re building, how much manual control you want over your infrastructure, and your long-term objectives for your service.
CloudFoundry is a great way to quickly deploy any application without having to think about infrastructure components. Most apps “just work” after a single cf push, drastically reducing the initial set up time and learning curve compared to Kubernetes. You don’t need to think about maintaining infrastructure over time or updating pieces of your stack: if your source code builds successfully, it can be deployed to CloudFoundry.
Kubernetes puts you closer to your infrastructure. You’re responsible for mapping your system’s architecture and determining the components you need for a successful deployment. This takes time and means you need to learn Kubernetes concepts and abstractions before you can begin. The benefit is increased flexibility and the option of creating infrastructure that more precisely matches your application’s requirements.
CloudFoundry is best when you want the highest level of automation and an opinionated design. It facilitates rapid deployments of large applications in a consistent and reproducible manner. CloudFoundry apps require relatively little maintenance over time, allowing them to be managed by smaller operations teams. Conversely Kubernetes is a more burdensome maintenance requirement but has become the standard for running heavily containerized systems in production. It’s the right choice when you need customization, flexibility, and clear visibility into your infrastructure components.
