The Fresh Prince of Cloud Native: Bringing Cloud Foundry & Kubernetes Together
In honour of Cloud Foundry Summit in Philadelphia next week..
Now this is a story all about how Cloud Foundry got flipped: turned upside down. So I’d like to take a minute — just sit right there — I’ll tell you how CF is becoming Cloud Native and why you should care.
In 2009, born and raised, in VMware was where it spent most of its days. Chillin’ out maxin’ relaxin’ all cool and all cf pushin’ some apps with a simplified tool.
When a couple of guys who were up to a lot of good started making trouble in the neighbourhood.
<Picture of Kubernetes Founders>
Ok, that’s enough of that. The point is I’d like to talk about how this little technology called Cloud Foundry might be the answer to how to do Cloud Native (and why the Eirini project — to use Kubernetes as the container scheduler in Cloud Foundry — might help it do that).
The Fresh PaaS
Cloud Foundry was — in a lot of ways — the original Enterprise PaaS. For a lot of workloads, all you really need is to be able to push code. You don’t need StatefulSets and Pods and Taints and Tolerances and Nodes and Dockerfiles and Registries and Schedulers (oh my). You need a platform that lets you push code, and then deals with scaling it and keeping it running with minimum fuss. Dare I say it: a Serverless platform (without all the Function-as-a-service stuff, which is a bigger leap).
But all that changed, and it changed for a good reason: we’re not ready. We still have stateful things we want to run ourselves (rather than consume as a service). We have databases, message queues, map/reduce clusters — and we need a way to run them. Enter Kubernetes.
Kubernetes. Kubernetes has become the standard container scheduler. Because it’s really good. Every major Cloud provider will sell you Kubernetes as a service, and there’s a huge ecosytem of folks who will sell you installers and tools for creating private Kubernetes clusters.
So you have — for good reason — a Kubernetes cluster. Why not use that to run the 80% of stuff that is-or-should-be stateless microservices? Why not just use Kubernetes Deployments and ReplicaSets and a few Dockerfiles and basically build your own PaaS?
Because: with great power comes great responsibility. Because just because you can use C/C++ to program all your stuff, and you need to use something low-level like C/C++to program some of your stuff, doesn’t mean you should use C/C++ for all of your stuff. High level languages let you go faster, more safely, and they do that by removing power. Also because yml sucks.
Cloud Foundry is the Enterprise Easy Switch
What I really want, as a developer, is a platform that lets me push code. Under the covers, that platform is going to have to worry about containers, and nodes, and servers. It will have to worry about patching and log management. DevOps means when things break in prod, I — the developer — am responsible for my code. And the way I have time for that is an Operator — someone else! — is responsible for the low-level, cross-cutting stuff: patching, scheduling, replacing nodes, rolling out updates, dealing with availability zones and so on. Cloud Foundry gives me a code-level API that doesn’t expose me to details about the how of how my code runs (because with great power comes great responsibility).
Project Eirini — which I’ll be talking about at CF Summit next week, please come! — lets you use Kubernetes as the container scheduler in Cloud Foundry. Why would you want to do that? Well..
Eirini For Developers
For Developers there are two big wins from Eirini. Firstly, if you want a Cloud Foundry cluster and you have access to Kubernetes but not VMs, Eirini lets you get it and kick the tires really fast. Secondly when you do need or want to pull the escape hatch and drop down to Kubernetes, everything you’ve cf push-ed is available as native Kubernetes objects under the covers.
Eirini For Operators
The big win from Eirini, though, is for Operators. Many platform operators already need to maintain a Kubernetes stack, for the stateless services their Cloud Foundry uses. Today, in order to provide an Easy Switch for developers, those operators need to manage two schedulers (Diego and Kubernetes), and any tooling and monitoring they use needs to be duplicated between the two. Deploying both the Diego and Kubernetes via Bosh can make this a bit better, but it doesn't solve the bulk of the problem. Eirini standardises the underlying infrastructure so it’s all Kubernetes under the covers.
Eirini at CF Summit 2019
If you’re interested in Eirini, or Cloud Foundry + Kubernetes in general, there are some great talks coming up at Cloud Foundry Summit in Philadelphia. Here’s a quick list of some:
- My Keynote Demo @ 9:20ish Wednesday April 3rd!
- Microservices with CF & Kubernetes @ 17:15 Wednesday
- Creating a Portable Cloud Foundry on Kubernetes @ 12:00
- Eirini Office Hours @ 15:15 Wednesday April 3rd
- Cloud Foundry 101 for Kubernetes Users @ 17:15 Wednesday
- “Kube Your Enthusiasm”: Our Full Eirini Update talk @ 11.05 Thursday 4th
- Diego vs. Kubernetes: How to Choose the best-fitting container scheduler @ 14:00 Thursday
- Zero to CF-on-K8s in 30 seconds @ 15:20 Thursday
Look forward to seeing y’all at CF Summit 2019!