Why does Cloud Foundry not use Eirini to deploy itself?

Or why we don’t feed our dogs with caviar?

Oleksandr Slynko
2 min readApr 14, 2020

I might be a little bit biased, but I think Cloud Foundry is a pretty good platform to run applications. Cloud Foundry on Kubernetes uses Eirini to schedule applications. However, it uses different applications to deploy itself. The obvious question is why does Cloud Foundry does not deploy itself using Eirini.

To answer this question, I will separate the applications in two big chunks — platform applications and user-facing applications.

Platform applications are usually rarely updated, some vendor provides a verified version and this version is installed on multiple servers. The important qualities of such applications are the reproducibility(especially after several weeks), the ability to find the exact version and correlate it with the code to debug it.

User-facing applications are updated more often, sometimes several times a day. Usually, only a single version is deployed. The speed of the build is more important for such applications, upgradability of the components is also quite important. The number of user-facing applications deployed is bigger than the number of platform applications. (If it is not the case, you are doing something wrong). In the end, the developer does not need to know all the limitations and best practices for the platform, so if something applies the best practices for a developer this is a big help.

Cloud Foundry can build the application, but there is no need to rebuild the component for each deployment, you should use prebuilt image. Cloud Foundry adds routes, but there is no need to add routes for system components. Most of user-facing applications don’t need access to Kubernetes API or Cloud Foundry API, so it should be not available from there; components rely on the access to Kubernetes API.

Cloud Foundry is one of the best places to run user-facing applications, but not so much for platform applications. This separation allows to prioritise more important features for Cloud Foundry components rather than adding support for Kubernetes configs.

Will this change? Probably. But or the nearest future the dogfooding won’t work. Cloud Foundry components need a different kind of food.

PS. This is my personal view and it does not represent my current and previous teams, employers, colleagues.

--

--

Oleksandr Slynko

Reading code for a long time, writing code for even longer.