I like to call CloudFoundry an “Application PaaS” and Kubernetes a “Container PaaS”, but the distinction is fairly subtle and fluid, given that both projects change over time to compete in the same markets.
The distinction between the two is that CF has a staging layer that takes a (12-factor) user app (e.g. jar or gem) and a Heroku-style buildpack (e.g. Java+Tomcat or Ruby) and produces a droplet (analogous to a Docker image). CF doesn’t expose the containerization interface to the user, but Kubernetes does.
CloudFoundry’s primary audience is enterprise application devs who want to deploy 12-factor stateless apps using Heroku-style buildpacks.
Kubernetes’ audience is a little broader, including both stateless application and stateful service developers who provide their own containers.
This distinction could change in the future:
- CloudFoundry could start to accept docker images (Lattice accepts Docker images).
- Kubernetes could add an image generation layer (OpenShift does something like this).
As both projects mature and compete, their similarities and differences will change. So take the following feature comparison with a grain of salt.
Both CF and K8s share many similar features, like containerization, namespacing, authentication,
Kubernetes competitive advantages:
- Group and scale pods of containers that share a networking stack, rather than just scaling independently
- Bring your own container
- Stateful persistance layer
- Larger, more active OSS community
- More extensible architecture with replacable components and 3rd party plugins
- Free web GUI
CloudFoundry competitive advantages:
- Mature authentication, user grouping, and multi-tenancy support [x]
- Bring your own app
- Included load balancer
- Deployed, scaled, and kept alive by BOSH [x]
- Robust logging and metrics aggregation [x]
- Enterprise web GUI [x]
[x] These features are not part of Diego or included in Lattice.
One of CloudFoundry’s competitive advantages is that it has a mature deployment engine, BOSH, which enables features like scaling, resurrection and monitoring of core CF components. BOSH also supports many IaaS layers with a pluggable cloud provider abstraction. Unfortunately, BOSH’s learning curve and deployment configuration management are nightmarish. (As a BOSH committer, I think I can say this with accuracy.)
Kubernetes’ deployment abstraction is still in its infancy. Multiple target environments are available in the core repo, but they’re not all working, well tested, or supported by the primary developers. This is mostly a maturity thing. One might expect this to improve over time and increase in abstraction. For example, Kubernetes on DCOS allows deploying Kubernetes to an existing DCOS cluster with a single command.