Cloud Foundry in transition
For many years, the term Cloud Foundry has stood for a production-ready technology for creating large application platforms. The "cf push" experience that is inextricably associated with Cloud Foundry is a key feature of this technology.
It provides developers with a convenient interface to operate application systems on their own. At the same time, Cloud Foundry also allows large organizations to operate efficiently (Bosh) and establish corporate standards (Buildpacks).
While the user experience over the years with a relatively high level of uniformity and stability favored the adoption of the technology in large corporations, Cloud Foundry's inner workings found themselves in constant flux. When the first conversations around combining Kubernetes with Cloud Foundry emerged, integrating Kubernetes as a container orchestrator was an obvious choice.
However, the marriage of Kubernetes and Cloud Foundry goes further and does not end with the management of app containers. To show the implications, recall that the infrastructure independence, stability, and - for large environments - low operational overhead do not come from Cloud Foundry itself, but from its sister technology Bosh.
Bosh is a rather underused and underappreciated technology that makes orchestrating stateful virtual machines as systematic and reliably writable as Cloud Foundry creates for stateless application systems.
However, the user interface is far less simple and requires some training. With the advent of Kubernetes, it was therefore initially conceivable that the Cloud Foundry stack would not have to change far. Operation could continue with Bosh and Kubernetes would be integrated as a container scheduler (Project Eirini).
Kubernetes' tremendous momentum doesn't stop at running stateless applications, however, as Cloud Foundry maintains. With the introduction of StatefulSets, Kubernetes is also able to handle stateful application loads.
This raises the aspirations of erstwhile OpenStack enthusiasts who dream of a free and standardized interface for virtual infrastructure (VM) orchestration. The hope is that Kubernetes will evolve into this generic technology, abstracting from the imperative and proprietary infrastructure APIs of public as well as on-premises cloud providers.
The enthusiasm for this is so great that, with unswerving faith, people also accept disadvantages, such as the significantly lower isolation, which containers bring with them compared to virtual machines. A disadvantage that can manifest itself especially in the collocation of databases on a Kubernetes node through mutual interference.
It is therefore not surprising that Cloud Foundry will continue to adapt to Kubernetes. An architecture draft from SAP, for example, addresses the question of whether a Kubernetes-based Cloud Foundry environment could map the large environments of the classic stack 1:1, and rather questions this. The limitations on both sides are too great.
Instead of promoting gigantomania of individual environments, the focus is rather on federalism. Separating the Cloud Control Plane consisting of API and UI from the container subsystem (Eirini) could help to make Cloud Foundry environments leaner and thus lower the barrier to entry for small CF environments. For example, a Cloud Foundry Control Plane could then serve many Kubernetes clusters or different Kubernetes clusters with dedicated tasks.
Time will tell which architectural approaches will be implemented and how strongly users will adapt them. The architect thinks, the user steers. In any case, there are exciting changes to observe.
