On the state of higher-level Container abstractions
For some reason, Medium highlighted a story from July last year, on the “demise of CloudFoundry” due to the underlying scheduler now being Kubernetes.
Now with the close of the Pivotal to VMWare buyback/acquisition, having worked within the CloudFoundry, early-container and Kubernetes ecosystems I felt like doing my first bit of 2020 writing as a late-but-hopefully-relevant response to why Kubernetes has nothing to do with it (directly).
The key point missing from the article is the very different expectations in user interaction between container orchestration, and platform as a service and ultimately, what matters and doesn’t matter to the end users of each.
While container orchestration is less opinionated, as a result it needs you to answer more of your own questions. Good for some, less good for others. It depends on your ‘** developer persona’.**
When it comes to the “what” of orchestrating the containers, it really doesn’t matter from a PaaS perspective, that’s not the value being offered by PaaS to the developer-persona that want’s to consume at the PaaS level.
As Onsi Fakhouri said in 2015 when CloudFoundry moved from their old container scheduler the DEA to Diego, “Here is my source code, run it on the cloud for me, I do not care how”.
DEA, DIEGO, Kubernetes, whatever, it’s an implementation detail in PaaS, not a talking point.
Down the rabbit-hole
Diego is an ETCD backed, distributed system for scheduling workloads in CGroup protected PID and network namespaces, via a scheduler, onto multiple nodes. Sound familiar?
Correct, Kubernetes could simplistically be described like that as well, so of course you’d try swapping out Diego for a massively maintained, ecosystem-leading version of the same thing, especially when it’s not your selling point, merely an engineering dependancy.
“Kubernetes should be boring”
https://twitter.com/kelseyhightower/status/920731336691740672
Inversely, while the opinionated persona of choice for 2020 may not be CloudFoundry, the demand of developer-personas with higher level abstractions than Kubernetes can be seen all over, consider the popularity of (to name a few):
- Openshift
A PaaS-style layer on top of Kubernetes. - KNative / OpenFaaS
And other serverless runtimes using Kubernetes as it’s back end scheduling and infrastructure provider. - I’d go as far to argue Helm charts and OperatorHub.io also highlight this trend, further abstracting away the complexities of consuming specific applications atop Kubernetes primitives.
TL;DR
… Although you scrolled to the bottom anyway! Thanks :)
These are all different personas, relevant to different people with different needs and use cases, this may just be because of their current level of experience into the cloud native ecosystem, or may be a hard and fast business/technology requirement.
The point is, if all of these workflows/pipelines boil down to containers, running on some infrastructure, and we have an orchestration layer that provides a single, run-anywhere, consistent API to power these higher level experiences, it makes operational, cost and stability sense to converge onto that underlying thing.
This isn’t new — efforts that have gone before
(and a very out of date plug!)
Back in 2016, my team saw the growing need for container consumption at multiple different levels of complexity and created a PoC of the CloudFoundry “persona” ontop of Mesos and Marathon and early-ish Kubernetes.
We called it ContainerCF, with the aim of providing containers for those that wanted them and the cloudfoundry experience for those that didn’t, all under a single resource stack.
A Similar effort was taken to production by Suse Linux ontop of Kubernetes in 2017/18.
Cloud Foundry Containerization for Kubernetes - SUSE Communities
The original article is here:
https://medium.com/@krishnan/lessons-from-the-demise-of-cloudfoundry-ed4f77a08a73
Just my 10 pence! Maybe medium will serve me up something from this decade next time!
Originally published on Medium on 14 January 2020.