Last month, Pivotal announced their flagship product - the Cloud Foundry based Pivotal Application Service - is coming to Kubernetes.

I requested access to the private alpha, and was allowed in. After adding some resources, I deployed it in my lab environment: PAS for Kubernetes deployed on Enterprise PKS on vSphere with NSX-T

After installation, a cf push was enough to get my application code to run as containers on Kubernetes.

So you may ask: “but wait, don’t applications deployed on Cloud Foundry run as containers since 2010?”
Yes.

“Doesn’t Cloud Foundry come with a container orchestrator (like Kubernetes) which runs all of these apps?”
Yes, it’s called Diego.

“Is it more complex?”
The opposite. It doesn’t require users to invest in container or container orchestrator knowledge.

“I guess it must be less mature than Kubernetes?”
Not exactly. It and its predecessor - the Droplet Execution Agent (DEA) - have run 100 thousands, if not millions, of applications in production in this world’s largest enterprise organizations for years. In fact, even before Kubernetes or Docker were even a thing.

“But we surely can do more with Kubernetes, right?”
Yes and no. Kubernetes has a lot more knobs and bolts for tweaking how applications run. However, it doesn’t yet have all the options Diego provides right now.

“I’m confused: given the above, why on EARTH would you want to replace Diego with Kubernetes?”
Because open-source is not a zero-sum game, and the magnitude of the positive sum is determined by the number of players.

“Come again?”
Like it or not, by now the number of organizations committed to Kubernetes is so huge, it’s pretty much guaranteed it will be the future of infrastructure, as the virtual machine was before it.

“So the idea is to profit from moving to a standard platform?”
The Cloud Foundry contributors will profit from not having to maintain their own custom container orchestrator anymore, as they can free up their best people to work on features higher in the stack that add more value.
Second, the Kubernetes community has such momentum, it’s likely more components of Cloud Foundry can be replaced in a similar way in the future when we start from the same point, thereby accelerating the first point.
Finally, customers specifically ask for it. Although the container orchestrator is still very much an implementation detail inside the much richer Cloud Foundry product, some people still care.

“Do we still need Cloud Foundry when we have Kubernetes?”
Nothing changed there. While Kubernetes may be the future of infrastructure, it’s not a developer platform.
Some think it is, but if you force - or allow - your developers to work directly with containers and container orchestrators, you can be certain they will spend the majority of their time on just that, instead of writing code that adds value for your business.

“So in PAS on K8s, does everything run as a container?”
No. Just the applications. Two years ago IBM started an initiative now called Eirini to swap the container orchestrator of Cloud Foundry from Diego to Kubernetes. Pivotal joined this year, and Pivotal Application Service (PAS) for Kubernetes (K8s) is the result.
There is another initiative - project Quarks - which aims at swapping the Cloud Foundry components - which are currently deployed using BOSH releases on virtual machines - to Kubernetes deployable Helm charts. That’s not yet in PAS on K8s. Besides, there are serious issues with the Helm package manager that need to be addressed before it becomes as solid as BOSH.

“So how is PAS for K8s?”
It’s a glimpse of the future. It’s awesome to see a cf push or cf scale result in running containers on Kubernetes.

The developer and platform engineer perspectives on PAS for Kubernetes

“Will the end user notice anything?”
Ideally, no. The end user of Cloud Foundry has always been the developer, and for them nothing changes. Note that this isn’t the first or the last time custom elements of Cloud Foundry are replaced by software that since has become the open source standard. For instance, the custom router tier is being replaced by the Istio service mesh, an effort that is well underway.

“How will it help our own customers?”
In the same way regular PAS does: by empowering them to create and deploy new business features faster and safer without downtime.