Cloud Foundry im Wandel
Der Begriff Cloud Foundry steht seit vielen Jahren für eine produktionsreife Technologie, um große Anwendungsplattformen zu erschaffen. Die untrennbar mit Cloud Foundry assoziierte „cf push“-Erfahrung ist dabei ein wesentliches Merkmal dieser Technologie.
Sie liefert Entwicklern eine bequeme Schnittstelle, um Anwendungssysteme in Eigenregie zu betreiben. Gleichzeitig erlaubt Cloud Foundry aber auch großen Organisationen einen effizienten Betrieb (Bosh) sowie die Etablierung von Unternehmensstandards (Buildpacks).
Während die Benutzererfahrung über die Jahre hinweg mit einer relativ hohen Einheitlichkeit und Stabilität die Adaption der Technologie in Großkonzernen begünstigte, fand sich das Innere Cloud Foundrys in konstantem Wandel. Als die ersten Gespräche rund um eine Kombination von Kubernetes mit Cloud Foundry aufkamen, war eine Integration von Kubernetes als Container-Orchestrator naheliegend.
Die Vermählung von Kubernetes und Cloud Foundry zieht aber weitere Kreise und endet nicht bei der Verwaltung von App-Containern. Um die Implikationen aufzuzeigen, ruft man sich noch einmal ins Gedächtnis, dass die Infrastruktur-Unabhängigkeit, Stabilität und – bei großen Umgebungen – geringen Betriebsaufwände nicht aus Cloud Foundry selbst herrühren, sondern aus der Schwester-Technologie Bosh.
Bosh ist eine eher wenig verbreitete und unterschätzte Technologie, die das Orchestrieren von zustandsbehafteten, virtuellen Maschinen so systematisch und verlässlich beschreibbar macht, wie das Cloud Foundry für zustandslose Anwendungssysteme schafft.
Das Benutzerinterface ist dabei allerdings weit weniger einfach und erfordert eine gewisse Einarbeitung. Mit dem Aufkommen von Kubernetes war es also zunächst denkbar, dass sich der Cloud-Foundry-Stack nicht weit verändern muss. Der Betrieb könnte weiterhin mit Bosh erfolgen und Kubernetes wird als Container-Scheduler integriert (Projekt Eirini).
Das enorme Momentum von Kubernetes stoppt aber nicht beim Betrieb von zustandslosen Anwendungen, wie das Cloud Foundry pflegt. Durch die Einführung von StatefulSets ist Kubernetes auch in der Lage, mit zustandsbehafteten Anwendungslasten umzugehen.
Dies weckt die Sehnsüchte einstiger OpenStack-Enthusiasten, die eine freie und standardisierte Schnittstelle für die Orchestrierung von virtuellen Infrastrukturen (VMs) erträumen. Die Hoffnung keimt, dass Kubernetes sich zu dieser generischen Technologie entwickelt und somit von den imperativen und proprietären Infrastruktur-APIs von öffentlichen sowie On-premises-Cloud-Anbietern abstrahiert.
Die Begeisterung hierfür ist so groß, dass man mit unbeirrbarem Glauben auch Nachteile, wie zum Beispiel die deutlich geringere Isolation, in Kauf nimmt, die Container gegenüber virtuellen Maschinen mit sich bringen. Ein Nachteil, der sich gerade bei der Kollokation von Datenbanken auf einem Kubernetes-Node durch wechselseitige Beeinflussung äußern kann.
So verwundert es auch nicht, dass sich Cloud Foundry weiter an Kubernetes anpassen wird. Ein Architekturentwurf von SAP widmet sich beispielsweise der Frage, ob eine Kubernetes-basierte Cloud-Foundry-Umgebung die großen Umgebungen des klassischen Stacks 1:1 abbilden könnte, und stellt dies eher infrage. Zu groß sind die Einschränkungen auf beiden Seiten.
Statt die Gigantomanie einzelner Umgebungen zu fördern, wird eher auf Föderalismus gesetzt. Eine Trennung der Cloud Control Plane bestehend aus API und UI vom Container-Subsystem (Eirini) könnte helfen, Cloud-Foundry-Umgebungen schlanker zu machen und so die Einstiegshürde für kleine CF-Umgebungen herabzusetzen. Eine Cloud Foundry Control Plane könnte dann beispielsweise viele Kubernetes-Cluster oder verschiedene Kubernetes-Cluster mit dedizierten Aufgaben bedienen.
Die Zeit wird zeigen, welche Architekturansätze zur Umsetzung kommen und wie stark die Adaption durch die Benutzer sein wird. Der Architekt denkt, der Anwender lenkt. In jedem Fall gibt es spannende Veränderungen zu beobachten.
