Bringing Cloud Foundry to Kubernetes users: how, why, and when

I have an exciting project to share. It’s a project that brings the Cloud Foundry experience – the rapid, simple development workflow for 12-factor applications we all love – to Kubernetes users with just a couple helm installs. It offers totally native Kubernetes scheduling for Cloud Foundry apps and no new operator burden in the process. (For now, it’s called “Project Eirini.”)

In this post, I’m going to cover three things: 1) I’ll tell you why Kubernetes users might want to try Cloud Foundry. 2) I’ll tell you why Kubernetes users might not want to try Cloud Foundry today, and I’ll what we’re doing to change that. 3) I’ll somehow leave you still wanting to come to our talk at the Cloud Foundry Summit where I’ll tell you 1 and 2 again.

Why Kubernauts might want to become Cloud Foundrynauts

Let’s get this out of the way: Kubernetes has won. Kubernetes has emerged as the clear winner for running containerized workloads. So why would you want anything else? Look at this way: even if you agreed that the JVM had won (anyone remember 2005?), that wouldn’t mean Groovy and Scala weren’t nice options to have.

What’s missing from Kubernetes for app developers? I’d argue: simplicity.

Kubernetes has amazing amounts of power, and with great power comes great responsibility. ReplicaSets, Nodes, Taints, Pods, Deployments, StatefulSets, Admission Controllers, Mutating Web Hooks, and Pod Security Policies are features you need if you’re building a platform to build platforms on, so it’s good they exist. As much as you really need low-level pointers if you’re building a language like C, it’s great that languages like Java and Ruby and Go exist, letting the majority of programmers not think about them.

Cloud Foundry offers a rapid serverless workflow for 12-factor apps. You don’t need to think about servers or nodes. You don’t need to think about AdmissionControllers or ReplicaSets or containers or state. And you don’t need to set up a cluster just to deploy an app: it’s multi-tenant safe, immediately secure, and very cheap for small apps and microservices. It’s as simple as possible, so you can focus on your actual business logic. But it’s powerful enough – with a whole foundation behind it and multiple public cloud providers offering it – to not get in your way.

Why not just use Cloud Foundry?

Let’s get this out of the way: Cloud Foundry has a fantastic developer user experience. I don’t believe there’s a better way, right now, to build 12-factor apps and microservices. And although massively distributed systems are cool to think about, most people should be thinking about 12-factor apps and microservices.

What’s more, Cloud Foundry has a fantastic custom-built scheduling technology (“Diego”) for 12-factor apps, and a custom deployment solution (“Bosh”) for standing it up on just about any cloud you might want to stand it up on.

So ou est la problema? The problem is a lot of folks want to use container technology to do more than manage their 12-factor apps. They want functions, they want stateful apps, they want databases, and they already standardized on Kubernetes as their substrate for running that environment. And they’re right. Kubernetes is a fantastic platform for running containerized workloads, and most developers have at least some workloads that benefit from Kubernetes.

So, for a lot of folks, you already have a Kubernetes cluster. You already have skills in maintaining and operating that cluster. You already have to monitor, patch, and upgrade that cluster. So when someone says “Hey, why not try CF?” it’s a lot to ask for you to start learning, maintaining, and operating an extra container scheduler. That’s the problem Eirini is trying to solve. For a lot of people who just need Cloud Foundry, the built-in scheduler is going to offer the best experience, doing only what’s needed for a platform as a service, and doing it very well. But for those who already have a Kubernetes cluster, Eirini lets you offer a cf push experience to your developers with the minimum amount of fuss, and with the minimum amount of new stuff to operate. And what’s more, the applications your developers cf push end up as first-class Kubernetes deployments, containers, and images. There’s nothing new to learn or manage, and it’s easy to integrate with your custom components like monitoring and image scanning.

So that’s Eirini. Now let me tell you why you should come see our Cloud Foundry Summit talk!

Why you should come see our talk, if you’re at Cloud Foundry Summit

At Cloud Foundry Summit Europe October 10-11, 2018 in Basel, Switzerland, we’re diving into the “how” of Eirini. But most excitingly, we give you a progress update of Eirini and a full demo of doing a cf push with Eirini.

Right now Eirini passes most of the cloud foundry integration tests, and it is installable to a Kubernetes cluster with just two helm installs (one for a whole Cloud Foundry without Diego, one for Eirini). There is no need to learn Bosh, and no need to learn Diego. Eirini is very simple and fast. After the helm installs are complete, we show how you can immediately set your developers up to cf push their apps, and how you can easily interact with the resulting deployments and services using kubectl commands.

You also get to see TWO people named “Julz” present. I’ve been a person named Julz for more than a couple of decades now, and let me tell you: this is a special treat. I look forward to seeing you all there!