Kubernetes and Diego 5: into the Eiriniverse
Progress on Kubernetes replacing Diego
NB: The opinions expressed in this post are my own and not necessarily those of my employer (or my PM).
Two years ago on Cloud Foundry summit, the question has been asked: “Will Kubernetes replace Diego?” At that time I answered no and wrote several articles with the explanation. Now after two years I work full time in the team that actually replaces Diego with Kubernetes. This is no longer a question. This year during Cloud Foundry summit in the Hague people were asking when Cloud Foundry will become Kubernetes-native.
The biggest selling point of Kubernetes — APIs. One can easily extend Kubernetes by adding more APIs. Using API is complex, annoying and unified. There are many integration points left for developers. People can easily replace networking, customise scheduling or modify requests on the fly. And since all these APIs operate on the same level, they should work with each other. Unfortunately, there is a downside — all is configured via APIs and you can never be sure that two things will work the same on two different clusters that located in different clouds. Multiple vendors bring another problem — it is impossible to configure clusters to work the same, there are multiple settings that it of users control. There is no such thing as a typical Kubernetes cluster. There is a conformance certification, but it covers only tiny part of Kubernetes features. It satisfies deploying of simple applications but does not help vendors.
This is where Diego and Cloud Foundry are better and simpler. No one needs to know all the details to deploy to the cluster. And by default, everything just works and works the same way everywhere.
Project Eirini simplifies application deployment. And it is feature complete. Ok, almost feature-complete — one can deploy an application, scale and delete it. What else do you need?
So Eirini is almost feature complete. Does it mean Cloud Foundry with Eirini supports all the little things that Cloud Foundry with Diego does? No. And it never will. Remember, I said there is no such thing as a typical cluster. That means there is no guarantee that all the features that we test will work in different clusters. But even if we could focus on a single type (for example IKS), we don’t support everything. There are things that are missing in core Kubernetes. But if we focus on features that Eirini team should deliver, there is not that much left.
So is it time to scale down Eirini team? I specifically focused on features, but there are many non-functional requirements that Eirini does not currently have. We have barely touched upgrades and performance. We haven’t worked on scalability. This should be the focus of the team.
I have never seen lift-and-shift to work for a long time. I don’t think it will work for Cloud Foundry as well. Eirini is just the first step. But it opens the door for future work. It starts Eiriniverse (non official internal name). It allows other teams start implementing features that will work the best way in Kubernetes and improve Eirini flow. There are many moving parts in Cloud Foundry and they provide great experience together, but right now they can’t be extracted and deployed separately or replaced easily. This contradicts with Kubernetes world and this is where I suppose Cloud Foundry will evolve — to a set of APIs that provide great experience to developers.
A few steps were already made in Eiriniverse — Suse is working on EiriniX and Pivotal is working on integrating kpack into Cloud Foundry. We will see how it looks in 6 months.
