Applying the Cloud Foundry workflow to Kubernetes
This is a topic that SUSE has been working on and maturing for a while.
Before we dive into what this means, let’s take a quick high-level look at what Cloud Foundry and Kubernetes are, and what they are not. Both Cloud Foundry and Kubernetes are go-to platforms when companies think of building modern cloud native applications. But they are not the same and really don’t try to be.
What is Cloud Foundry?
Cloud Foundry is an open source cloud platform as a service (PaaS) on which developers can build, deploy, run and scale applications.
What is Kubernetes?
Kubernetes is an open-source platform designed to automate deploying, scaling, and operating application containers.
What is interesting about these simple statements is the difference in scope. This is important.
Cloud Foundry states they are there to help build, deploy, run and scale. Kubernetes states they help with deploying, scaling, and operating. The key difference, Cloud Foundry’s focus on the front-side to facilitate building your applications. But both platforms talk to how they handle deployment, operations, and control scale.
A way I like to look at this, Cloud Foundry helps the developer focus on the workloads that will be built and run in containers, Kubernetes focuses on supply everything needed to operate and manage at the container level.
Where this leads to confusion, both environments run containers. So many think they are basically the same. They aren’t. At least not from the experience the developer will have when building and deploying applications.
Kubernetes by itself is not primarily focused on what you are running in the container. Of course as everyone will point out, you can surround Kubernetes with the needed infrastructure or a developer can manually account for this. But the point is, while there are a great number of infrastructure and methods that can be implemented to help you do more than run and manage containers, these additional needs are for you to account for.
The reality, Kubernetes is becoming a ubiquitous answer for the operational side of the container world.
Cloud Foundry has a fundamentally different approach to this due to its differing scope. Cloud Foundry is there to provide you an incredibly easy path to both package and deploy your applications – bind services like messaging, DBs, and monitoring while compiling and building your containers all as part of the simple deployment statement like “cf push myapp …”. Cloud Foundry brings a great deal of templated style workflow that developers can leverage. Basically, the developer can let the platform help where they don’t want to spend time. This is proven workflow with years of use in the enterprise and has been in the market for longer than Kubernetes has existed.
Now, the key issue that we at SUSE have heard talked about repeatedly, “Should I run my cloud native applications on Kubernetes or should I use Cloud Foundry?” What if I told you, do both. Use Kubernetes to deploy and manage your containers, but take advantage of the Cloud Foundry workflow by installing it into your Kubernetes clusters.
This is what SUSE has been working on with our SUSE Cloud Application Platform. With this approach, you can install a containerized Cloud Foundry, a Kubernetes orchestrated application itself, into target Kubernetes clusters. The end result, you can have a Cloud Foundry developer rich workflow in the up and coming ubiquitous Kubernetes container platform.
Thanks. If I copy/paste this and replace “CloudFoundry” with SCAP , and Kubernetes with CaasP” , is there a single part of what has been written which would not be true ?
Your point is correct. SUSE Cloud Application Platform is a conterized version of cloud foundry that can be installed into a Kubernetes cluster like the one provided by SUSE Container as a Service Platform.