Cloud Foundry vs Kubernetes: Which One Should You Choose?

Should you choose Cloud Foundry PaaS over Kubernetes for your next application deployment platform, or maybe try both?

When designing a microservices-based application from scratch, the choice of the application deployment platform is of the utmost importance. No matter if you choose to build your platform on bare metal servers, IaaS (Infrastructure as a Service) base like Google Compute Engine or use a complete PaaS (Platform as a Service) solution, it will be your first step defining the workflow of maintaining and deploying your application code.

Choosing the right platform can make your software developers focus more on providing new application features instead of spending more time on packaging and deploying the code each time they want to release a feature or a bug fix.

How is Infrastructure as a Service different from Platform as a Service?

As you can see in the table, the PaaS solution creates the highest level of abstraction, taking most of the management work away from your team and puts it on the platform itself.

That allows the developer to simply “push” the application for deployment and let our cloud take care of the rest. Leaving the infrastructure management to the platform, they can simply focus on delivering business value for your product.

That obviously comes with a cost of flexibility, making advanced customization of your app instances a little harder than on the IaaS-based platform. Widely used Kubernetes is a system using ideas from both IaaS and PaaS while focusing mainly on containers orchestration.

But what if you don’t want to use Kubernetes for some reason? In that case, the Cloud Foundry project is the way to go.

Cloud Foundry vs Kubernetes: Similarities and Differences

As Cloud Foundry Foundation says, “Cloud Foundry is a dollhouse, and Kubernetes is a box of building blocks from which you can create a dollhouse”.

Cloud Foundry shares features with Kubernetes but is a higher-level abstraction of cloud-native application deployment. As the platform creators say: you give it the application, and it does the rest. It understands the application dependencies, builds the container, deploys it, scales it, connects it to the network, and routes the traffic to it. That allows the developer to focus only on the application code. That’s why Cloud Foundry says that the main unit of currency for the platform is the application.

How does it compare to Kubernetes? Because Kubernetes’ main unit of currency is the container, it puts additional complexity on developers’ work, making them build the container for the app and provide other deployment configurations, while Cloud Foundry frees them from doing that. In other words, Kubernetes hides nothing from the developers, making developers and operators interact with it in the same way, while Cloud Foundry provides a different experience for cloud operators and cloud developers, simplifying the interface offered to the latter.

Effortless Services Available on the Marketplace

Cloud Foundry abstraction also covers what’s called the “services”, which is a concept missing in Kubernetes.

CF Services are specific on-demand applications, such as relational and non-relational databases, message brokers, caching solutions, etc. It uses the concept of “service brokers” to allow any operator (including a software developer) to provision an instance of the service and bind it to any application without the need to manually provide the service details to it.

The broker takes care of setting up the connection using the application environment – that allows, for example, a Java Spring application to automatically pick up the database connection details and use that as the main app data source. So from a developer perspective, connecting the application to a new database instance consist of just two simple commands – one to provision a database service instance, second to bind the service to the app instance.

Also, all brokers installed on the platform are available from the “marketplace” which is a central place where the operator or developer can find a specific service, check available plans, and quickly provision a service instance.

Freedom to Run the Platform Anywhere

The next important difference is that while Kubernetes might be burdensome to run on your infrastructure, Cloud Foundry is made to host workloads on any equipment, whether it’s on-premise, a public cloud, a bunch of plain VMs! Also, it allows the operators to transfers the workloads between all the possible options in a matter of minutes, with no need to change the app whatsoever.

To summarize all of the above, Cloud Foundry works on a high-level of abstraction, offering a higher level of productivity to its users, especially for application developers, but that comes with some limitations concerning customization in the runtime. It is a great choice for new, cloud-native apps and smaller teams working in short lifecycles and frequent releases.

Kubernetes, on the other hand, is a lower-level abstraction that can serve as a base for building your customized deployment platform, providing you with greater flexibility. However, it puts some additional work on your teams, sometimes causing a decrease in productivity.

Kubernetes, Cloud Foundry or Both?

Having that in mind, why not get the benefits of both systems? Kubernetes is built to support any workload, so that means we can deploy Cloud Foundry also on Kubernetes!

There are two open-source projects (namely KubeCF and cf-for-k8s), which allow Cloud Foundry to run workload on the same K8s cluster on which the Cloud Foundry platform is deployed. Cloud Foundry Container Runtime is then used to deploy workloads using a mix of BOSH and Kubernetes. It provides users with the customization abilities of Kubernetes and the deployment and management power of the CF platform. It’s all possible thanks to the wonderful Project Eirini which is still one of the developing projects of the Cloud Foundry Foundation. Who knows, maybe it will be the future and the new abstraction layer connecting IaaS and PaaS approaches.

So, as you can see, it’s not possible to choose one best solution when it comes to cloud-native application deployment platforms. Depending on the complexity of your project, the size of your team, and other factors, you may go for one of many available approaches.

Kubernetes is one of the most used solutions worldwide and might be used for any workload one can think of. However, when you have more general needs and want to focus on your developers providing business value instead of worrying about deployment configuration, then Cloud Foundry will be the best way to do it.

You can also use Cloud Foundry deployed directly on Kubernetes to enjoy the benefits of both worlds combined.

Enterprise Cloud Foundry Offerings

If you’re interested in using Cloud Foundry as your cloud platform but are worried if you and your team can fully manage the complicated open-source solution, there are also several commercial offerings available, which include professional support services and may or may not be provided with underlying infrastructure.

One of the most popular is VMWare Tanzu(formerly Pivotal Cloud Foundry), which is also available on the most popular public cloud platforms, like Azure. If your company wants a production-ready platform without the hassle of maintenance, then enterprise Cloud Foundry distributions like these are the way to go.

Try Cloud Foundry Hands-on

If you are one of the people that need to try something in practice first, Cloud Foundry offers a cf dev project which allows you to test the whole platform while deploying it on a single device (for example your work laptop).

If you still need some more guidance, you can check our other article with practical exercises showing the features and capabilities of the Cloud Foundry platform.