How to know when you should choose PCF versus Kubernetes, and when you should choose… both
There’s a lot of temptation to compare Pivotal’s Cloud Foundry (PCF) and Kubernetes (K8s) to each other, we get it. They’re both platform services for deploying cloud-native apps, and they both deal with containers, and the list goes on.
There’s a lot of functional overlap between PCF and K8s, but it’s important to understand how they differ from each other. In this post, we’ll cover the basic differences between the two, when it’s best to use one rather than the other, and when it’s best to use them together.
Psst! Getting ready to move your app to cloud-native and/or containers? OverOps fills the gaps that log analyzers and APMs (and even tracing tools) don’t cover, giving you an overall picture of application quality plus True Root Cause for all errors and slowdowns.
What’s a PaaS?
In 2006, Amazon launched their Amazon Web Services (AWS) public cloud platform, and a new era began. The era of cloud-native applications. But what does it mean to build and run an application on the cloud? Nowadays, more than 10 years after the introduction of AWS, there are 3 levels of cloud-service abstractions: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).
Amazon Elastic Compute Cloud (EC2) falls into the IaaS category, giving users the basic infrastructure needed to build and deploy an application. The next level is PaaS products, which will be the topic of this post. PaaS products offer a higher level of abstraction, so the user won’t be exposed to the O/S, middleware or runtime and needs only to concern him or herself with the application and data. And lastly, SaaS products are applications built and hosted by a third-party platform and made available to users via the internet.
A PaaS is a platform upon which developers can build and deploy applications. These products offer a higher level of abstraction than we get from IaaS products meaning that, beyond networking, storage and servers, the application’s O/S, middleware and runtime are all managed by the PaaS.
Within the PaaS market, two of the major players are Pivotal Cloud Foundry and Kubernetes. They are both open source cloud PaaS products for building, deploying and scaling applications. Despite having large areas of functional overlap, these two systems offer very different capabilities to their users and are each better suited for different circumstances.
“Application” PaaS vs. “Container” PaaS
Pivotal Cloud Foundry and Kubernetes share many similar features like containerization, namespacing, and authentication but their overall approaches to the deployment of cloud-native applications differ greatly.
The difference between an “application” PaaS and a “container” PaaS isn’t so difficult to figure out. When we talk about abstractions, we can simply break the PaaS level into two pieces. On the one hand, we have the platform abstraction at the application level, building and deploying a fully-configured application, and on the other hand, we have the platform abstraction at the container level, building and deploying containers as a part of a complete application.
PCF is one example of an “application” PaaS, also called the Cloud Foundry Application Runtime, and Kubernetes is a “container” PaaS (sometimes called CaaS).
The bottom line is that it doesn’t have to be an ‘OR,’ it can be an ‘AND’. The question isn’t necessarily whether you should use Cloud Foundry OR Kubernetes, the question is when you may need one AND/OR the other.
Because of a few key differentiators, they can be used together demonstrated in the way they complement each other in the Cloud Foundry Container Runtime, an open-source collaboration between Pivotal and Google (more on this later).
Pivotal Cloud Foundry
Pivotal Cloud Foundry is a high-level abstraction of cloud-native application development. You give PCF an application, and the platform does the rest. It does everything from understanding application dependencies to container building and scaling and wiring up networking and routing.
Applications run on Cloud Foundry are deployed, scaled and maintained by BOSH (PCF’s infrastructure management component). It deploys versioned software and the VM for it to run on and then monitors the application after deployment. Although the learning curve for BOSH is considered to be fairly high, once mastered it adds considerable value by boosting team productivity.
- More basic features of Pivotal Cloud Foundry include:
- Cloud Controller to direct application deployment
- Deploy using Docker Images and Buildpacks
- Automated routing of all incoming traffic to appropriate component
- Instant (vertical or horizontal) application scaling
- Cf CLI (PCF command line interface)
- Cluster scheduler
- Load balancer and DNS
- “Loggregator” – Logging and metrics aggregation
Installation and Usability
Before beginning the installation process for Pivotal Cloud Foundry, Pivotal documentation directs users to configure their firewall for PCF and establish IaaS user role guidelines. After that, installation is guided by a web user interface.
Best Use Cases
Cloud Foundry’s platform is a higher-level abstraction and so it offers a higher level of productivity to its users. With productivity, though, comes certain limitations in what can be customized in the runtime.
PCF is ideal for new applications, cloud-native apps and apps that run fine out of a buildpack. For teams working with short lifecycles and frequent releases, PCF offers an excellent product.
[easy-tweet tweet=”PCF is ideal for new applications, cloud-native apps and apps that run fine out of a buildpack. #pivotal #cloudnative” url=”http://bit.ly/2YjC8ty” user=”overopshq” template=”lite”]
Kubernetes is a container scheduler or orchestrator. With container orchestration tools, the user creates and maintains the container themselves. For many teams, having this flexibility and control over the application is preferred.
Instead of focusing only on the app, the developer needs to create the container and then maintain it in the future, for example, when anything on the stack has an update (a new JVM version, etc.).
Kubernetes is a mature container orchestrator that runs in the same market as Docker Swarm and Apache Mesos. In Kubernetes, containers are grouped together into pods based on logical dependencies which can then be easily scaled at runtime.
More basic features of Kubernetes include:
- Master node for global control (scheduling, API server, data center)
- Worker nodes (VM or physical machine) with services needed to run container pods
- Auto-scaling of containers and volume management
- Flexible architecture with replaceable components and 3rd party plugins
- Stateful persistence layer
- Kubectl (Kubernetes command line interface)
- Active OSS community
Installation and Usability
A common complaint that users have about Kubernetes is the difficulty of the setup process. First of all, you have to plan ahead when starting to implement K8s because you have to define your nodes in advanced, which can be very time consuming. On top of that, setting up Kubernetes varies for each OS, and the documentation isn’t sufficient in cases when users need to build custom environments. Add to all of that manual integrations that are required, and even thinking about going through the setup process can give you a headache.
Once it’s ready to use, though, Kubernetes offers the most mature and most popular service on the market in terms of container orchestration tools. It also has an active community offering support and resources to users.
Best Use Cases
Kubernetes is a lower-level abstraction in the PaaS world meaning greater flexibility to implement customizations and build your containers to run how you want them to run. Unfortunately, this also means more work for your engineering teams and decreased productivity.
When moving to any new system or product, a good rule of thumb is to use the highest level abstraction that will solve your problem without putting any unnecessary limitations on the workload. If you need more flexibility to do customizations, and you’re willing to put in the work, stick with Kubernetes (or check out Kubo below).
[easy-tweet tweet=”If you need more flexibility to do customizations, and you’re willing to put in the work, stick with Kubernetes (or check out Kubo). #kubernetes #cloudnative” url=”http://bit.ly/2YjC8ty” user=”overopshq” template=”lite”]
Best of Both Worlds: Cloud Foundry Container Runtime
The Cloud Foundry Container Runtime (CFCR), previously called Kubo, basically takes Kubernetes and runs it on top of BOSH, Cloud Foundry’s open-source lifecycle management tool. The goal of this collaboration between Pivotal and Google, the creator of Kubernetes, is to create “a uniform way to instantiate, deploy, and manage highly available Kubernetes clusters.”
CFCR gives users the customization abilities of Kubernetes with the deployment and management power of BOSH.
It can be tempting to try to make an exact 1-to-1 comparison between different tools and services on the market. It’s easier to make decisions that way. But sometimes, tools and services that appear to be in competition with each other actually offer complementary capabilities.
The fact of the matter is, Pivotal Cloud Foundry and Kubernetes have some functional overlap, but they serve two different purposes. So, choosing the right tool for you means looking more closely at what you need it for and how you plan to use it. And for the best of both worlds? Look into the Cloud Foundry Container Runtime.
Psst! Getting ready to move your app to cloud-native and/or containers?OverOps fills the gaps that log analyzers and APMs (and even tracing tools) don’t cover, giving you an overall picture of application quality plus True Root Cause for all errors and slowdowns.