(Zurück) zu VMware, hin zu Kubernetes Cloud Foundry: Infrastrukturagnostische Bereitstellung Cloud-nativer Microservices

Das Lifecycle-Management verteilter Anwendungen könnte wohl kaum noch komplexer werden. Applikationen schneller bauen, testen, skalieren und infrastrukturagnostisch bereitstellen: Genau diese Versprechen hat sich das quelloffene Projekt Cloud Foundry auf die Fahnen geschrieben.

Anbieter zum Thema

Dell GmbH

VMware Global Inc Zweigndl. Deutschland

DataCore Software GmbH

Cloud Foundry Foundation

Aus Sicht von Unternehmen wie der Datev e.G., des genossenschaftlich organisierten deutschen IT-Dienstleisters für finanzregulatorische Angelegenheiten, ist die „Cloudifizierung“ der Anwendungsentwicklung und -Bereitstellung eine heikle Sache. Das Unternehmen bedient aus seinem hochsicheren, nach ISO 27001 zertifiziertem Rechenzentrum in Nürnberg mehr 325.000 Kunden, darunter Steuerberater, Wirtschaftsprüfer, Rechtsanwälte, zahlreiche mittelständische Unternehmen, Behörden und andere Organisationen – also Mitglieder und Unternehmen sowie Behörden, die die Produkte direkt nutzen.

Die Datev verwaltet, mit mittlerweile über 50 Jahren Erfahrung, für seine ihre Mitglieder hochsensible Daten, darunter eine Milliarde revisionssicher archivierter digitaler Belege, und übermittelt jeden Monat zirka 13 Millionen Lohnabrechnungen. Im Hinblick auf den Datenschutz darf hier rein gar nichts schief gehen.

„Die Daten in unseren Rechenzentren sind strengstens abgesichert, im Einklang mit deutschem Recht“, betont Jürgen Sußner, Cloud Platform Engineer im Cloud Competence Center der Datev in Nürnberg. In dem Air Gapped-Netzwerk der DATEV unterliegt alles strengsten Kontrollmechanismen. Der Weg in die Public-Cloud ist dem Unternehmen de facto versperrt.

Her damit: „Die Cloud“ 'mal eben ins eigene RZ holen

Im Laufe der Jahre ist die Datev vom Rechenzentrumsdienstleister zum Anwendungsentwickler gemorpht. Die mehr als zwei tausend Entwickler der Datev benötigen eine flexible und verlässliche Cloud-Plattform, um konkurrenzfähig zu bleiben.

Eine eigene Cloud-Plattform musste also her. Diese hat die Datev in der dicht abgeschirmten Umgebung des hauseigenen Rechenzentrums eingerichtet, und zwar mit Cloud Foundry. „[Wir haben] die Technik von Public Clouds zu uns ins Rechenzentrum geholt“, freut sich Sußner.

Cloud Foundry bei T-Mobile

Zu den prominentesten Nutzern von Cloud Foundry zählt außerdem T-Mobile. Die nordamerikanische Tochter des deutschen Mobilfunkanbieters hat Cloud Foundry zur „strategischen Wachstumsplattform“ gekürt. Die autark skalierbare verteilte Anwendung, bestehend aus containerisierten Microservices, konnte bereits kurz nach der Inbetriebnahme über 40 Millionen Transaktionen pro Tag verarbeiten.

Als ein angenehmer Nebeneffekt der Umstellung von T-Mobiles alter monolithischer Java-Applikation für „Weblogic“ auf Microservices in Cloud Foundry konnte das Unternehmen den Entwicklungslebenszyklus seiner Software von sieben Monaten auf bloß Tage verkürzen. (Im Stack kommen außerdem „Java“, „Spring Cloud Services“, „LeoFS“, „MySQL“, „RabbitMQ“, „Apigee Edge“, „Kubernetes“, „Swagger“ und andere Produkte zum Einsatz.)

Das Eisen schmieden, solange es heiß ist

Bei „Pivotal Cloud Foundry“ (kurz: PCF) handelt es sich um eine quelloffene „as-a-Service“-Plattform (PaaS) für die Cloud-agnostische Ausführung verteilter Anwendungen. (Das Wort „Foundry“ im Englischen bedeutet so viel wie eine Metallgießerei, eine Art „Werkstatt“ in der Stahlindustrie.)

Cloud Foundry entkoppelt die Anwendungen von der darunter liegenden Infrastruktur, um ihnen die Fähigkeit zur Cloud-agnostischen Bereitstellung zu verleihen. Mit Cloud Foundry können Unternehmen ihre Hosting-Umgebung ganz individuell und dynamisch gestalten. Die Anwendungsausführung lässt sich zwischen On-Prem, öffentlichen Clouds und verwalteten Infrastrukturen in wenigen Minuten migrieren; der Anwendungscode bleibt dabei unverändert.

Heute findet die Entwicklung von Cloud Foundry (Kurzbezeichnung: CF) unter der Obhut einer gemeinnützigen Organisation statt, der Cloud Foundry Foundation. Die Stiftung genießt tatkräftige Unterstützung unter anderem von Google, IBM, Microsoft, Pivotal/VMware, SAP, SUSE und anderen. Die CF-Plattform unterliegt der Apache-2.0-Lizenz.

Durchhaltevermögen und Unbefangenheit

Der lange Werdegang der CF-Plattform von einer rein proprietären Lösung zu dem, was sie heute ist, begann im Hause VMware. Die Wurzeln von Cloud Foundry (kurz: CF) gehen auf das „Project B29“ zurück, welches in einem kleinen Entwicklerteam bei VMware unter der Leitung von Derek Collison im Rahmen der „VMware Cloud Application Platform“ vor rund zehn Jahren Geschichte hybrider Clouds schrieb.

Zu jenem Zeitpunkt machte der Name „Cloud Foundry“ bereits in einem ganz anderen Kontext die Runden. So hieß nämlich ein nicht verwandtes PaaS-Projekt, welches zwar in Java geschrieben worden war, aber nur auf „Amazon EC2“ lief. Im Zuge mehrerer Akquisitionen fand die Java-Lösung für EC2 zu guter Letzt ihr Heim bei VMware und wurde hier kurzerhand eingestellt. Der Name „Cloud Foundry“ blieb aber hängen.

Mit der Ankündigung der heutigen Cloud Foundry — gleicher Name, völlig anderer Code — hatte sich VMware bis April 2011 Zeit gelassen. Die Software sollte mehrere Cloud-Umgebungen nahtlos überbrücken können, um den infrastrukturagnostischen Betrieb verteilter Anwendungen zu ermöglichen.

Für die Orchestrierung zeichnete anfangs Chef verantwortlich. Der Ansatz scheiterte kläglich an unzureichender Skalierbarkeit, umständlichen VM-Updates und den nicht-vorhandenen Health-Checks. Eine andere Lösung musste schleunigst her. So entstand ein eigener Orchestrierer von Cloud Foundry: „BOSH“.

Die Toolchain

Bei BOSH handelt es sich um ein quelloffenes Toolchain für das Release-Engineering, die Bereitstellung und das Lebenszyklus-Management von hochskalierbaren verteilten Diensten.

BOSH erblickte das Licht der Öffentlichkeit im April 2012. Ein weiteres Jahr später, im April 2013, ging das Unternehmen Pivotal aus EMC und VMware hervor. Pivotals Aufgabe sollte darin bestehen, Vermögenswerte wie eben Cloud Foundry, „RabbitMQ“, „Spring“ und andere zu vermarkten. Diese weitsichtige Management-Entscheidung bescherte den Entwicklern von Cloud Foundry die nötige „Isolierung“ von den übrigen Einflussgrößen der Unternehmensgruppe, um Unbefangenheit zu gewährleisten.

BOSH unterstützt heute mehrere Infrastrukturumgebungen, darunter neben „VMware vSphere“ und „OpenStack“ auch die „Google Cloud-Plattform“, „Amazon Web Services EC2“, „Microsoft Azure“ und „Alibaba Cloud“. Mit Hilfe der eigenen CPI-Schnittstelle (Cloud Provider Interface) lässt sich BOSH um zusätzliche IaaS-Anbieter wie „Apache CloudStack“ und „Virtual Box“ erweitern. Diese Unabhängigkeit zählt zu den unverkennbaren Stärken der Plattform.

Erfolgsgarant Unabhängigkeit

Heute nutzen mehr als die Hälfte der Fortune 500-Unternehmen das Open-Source-Projekt Cloud Foundry zum Erstellen, Testen und Bereitstellen ihrer Anwendungen Cloud-agnostisch, entweder selbst oder über Anbieter wie Pivotal. Im August 2019 wurde die Übernahme von Pivotal durch VMware vollzogen.

Die „Stammzellen“ Cloud-agnostischer Anwendungen

Cloud Foundry setzt sich aus verschiedenen Hauptkomponenten zusammen, die entweder ineinandergreifen oder sich gegenseitig auswechseln. Die Plattform verfügt zum Beispiel über nicht eine, sondern genau genommen zwei alternative Runtimes:

• „CFAR“ (Cloud Foundry Application Runtime) ist eine Laufzeitumgebung zur Bereitstellung von Code in beliebigen Programmiersprachen, mit beliebigen Frameworks und auf beliebigen Clouds; dank der Open Service Broker-API erstrecken sich die Fähigkeiten der CFAR auch auf zusätzliche Dienste; die Bereitstellung erfolgt via Cloud Controller

• „CFCR“ (Cloud Foundry Container Runtime, bekannt unter der Bezeichnung. „Kubo“) bietet im Zusammenspiel mit BOSH, einem CF-eigenen VM-Orchestrierer eine fortgeschrittene Unterstützung für die zuverlässige, selbstheilende Bereitstellung zustandsloser „12-Factor“-Apps und Microservice-Meshes auf Kubernetes; die Verfügbarkeit von Storage lässt sich durch externe Dienste gewährleisten.

Mehrere Hundert weitere Komponenten liefern ergänzende Funktionalität, darunter:

• „BOSH/Ops Manager“ provisioniert eine selbstheilende Bereitstellung von Infrastrukturressourcen mit Hilfe von „BOSH Director“ auf der Basis von IaaS-spezifischen Manifest-Dateien in „YAML“ für die Anwendungsausführung in CFCR

• „Cloud Controller“ handhabt die Anwendungsbereitstellung und -Ausführung in der CFAR

• „Gorouter“ leitet die Kommunikation der Applikations- und Systemebene; weitere Initiativen, darunter „Istio“ und „Envoy“, sollen die Netzwerkfähigkeiten von Cloud Foundry um fortgeschrittene Routing-Features erweitern

• „Diego“, der CF-eigene integrierte Scheduler, verwaltet die Anwendungsausführung und die Runtime und orchestriert das hauseigene Container-Format Garden

• „Loggregator“ sammelt Logs und andere Metriken für die optionale Integration mit externen Lösungen wie von Splunk, Logstash, New Relic, Datadog und Dynatrace

• der „UAA“-Server (User Account and Authentication) ist die zentrale Anlaufstelle für alle Anfragen an das Identitäten- und Zugriffsmanagement auf Cloud Foundry, einschließlich „OAuth2“

• die Open Service Broker API bindet externe Dienste an CF-Anwendungen (Cloud Controller fungiert als Client für die API; der Service-Anbieter muss die API implementieren, zum Beispiel durch die Bereitstellung der benötigten HTTPS-Endpoints)

Cloud-agnostische „Containerisierung“ mit CFCR

Die Cloud Foundry Container Runtime (kurz: CFCR a.k.a. Kubo) verwaltet Container mit Hilfe von BOSH und Kubernetes; BOSH ermöglicht hierbei die nahtlose Ressourcenprovisionierung auf jedem beliebigen Infrastrukturunterbau mit Zero-downtime-Upgrades und automatischer Wiederherstellung der Kontrollebene von Kubernetes. Die CFCR wurde von Pivotal in Zusammenarbeit mit Google, VMware und Swisscom entwickelt.

Die Initialisierung einer Bereitstellung von PCF mit CFCR und BOSH läuft recht überschaubar ab:

BOSH Director orchestriert VMs, die auf den so genannten Stammzellen (Engl. stem cells) aufsetzen. Hierbei handelt es sich um eine Art Vorlagen mit einem Basisbetriebssystem, dem BOSH-Agenten zur Uptime-Überwachung sowie allen erforderlichen Dienstprogrammen und Konfigurationsdateien. Stammzellen bilden wiederum die Grundlage für die so genannten Releases, also versionierte Sammlungen von Konfigurationseinstellungen, -Vorlagen, Startup-Skripten und anderem Quellcode, Binärdateien, und allen anderen Komponenten zum Ausführen eines bestimmten Softwarepakets auf der jeweiligen VM.

BOSH Director kann mit nahezu beliebigen Public- und Private-Clouds, etwa Azure, GCP und AWS, Virtualisierungsplattformen und dergleichen anderen Infrastrukturumgebungen kommuniziert, um VM-, Storage und Netzwerkressourcen für die Container-Orchestrierungsengine (Kubernetes oder eine andere) anzufordern. Der quelloffener Container-Orchestrierer Kubernetes meistert die hyperskalierbare Anwendungsbereitstellung, bietet jedoch keinerlei zuverlässigen Health-Checks für die darunter liegende Infrastruktur.

Sonderfall: Windows-Workloads

Nur BOSH kann beschädigte VMs wiederherstellen; Kubernetes selbst kann die zugehörigen Container lediglich auf den übrig gebliebenen VMs neu initialisieren. Für die Kapazitätswiederherstellung zeichnet in CF BOSH verantwortlich. (Die Unterstützung von Windows-Workloads scheitert im Übrigen am Networking.)

PCF verpackt die BOSH-API in die Web-basierte grafische Benutzeroberfläche des Ops Managers, um die Administration und Automatisierung zu erleichtern. So kann der Administrator mit Hilfe des Ops Managers die benötigten Optionen visuell konfigurieren, die benötigten Manifest-Dateien automatisch erzeugen und an BOSH Director übertragen. Der Ops Manager bietet außerdem eine grafische Benutzerschnittstelle für einige Erweiterungen und Dienste zur Überwachung der Anwendung.

Der VM-Orchestrierer BOSH trennt das OS von den bereitgestellten Diensten, so dass sich diese Elemente jeweils einzeln und unabhängig voneinander aktualisieren lassen (etwas, was „Chef“ nicht gewährleisten konnte). BOSH überwacht jeden Prozess und jede einzelne VM mit Hilfe von DNS-gestützten Health-Checks, um eine mehrschichtige Hochverfügbarkeit zu gewährleisten. Zur Vereinfachung des Managements von Zugangsberechtigungen greift BOSH auf „CREDHUB“ zurück, einen Speicher für Credential-Informationen und andere sensible Zugangsdaten.

Cloud Foundry und Kubernetes

Wie so viele andere Projekte einschließlich OpenStack konnte sich auch Cloud Foundry in den letzten Jahren der Containerisierung der Unternehmens-IT nicht entziehen. Die Integration von „Red Hat Openshift“ mit Kubernetes und das nicht ganz überraschende Aufkommen von quelloffenen Projekten wie Istio, einem Lastverteiler für Kubernetes, haben der CF-Gemeinde offenbar zu denken gegeben.

Keine Liebe auf den ersten Blick

Es ist kompliziert - Cloud Foundry und Kubernetes

Aktuelle Bemühungen rund um die Weiterentwicklung von CF im Einklang mit den Prioritäten der Nutzergemeinde fokussieren auf die Entkopplung von Elementen der Plattform zur Gewährleistung einer höheren Flexibilität und einer vollständigeren Abdeckung möglicher Bereitstellungsszenarien. Zwei aktuelle Initiativen in diesem Bereich sind die Projekte Eirini (ursprünglich von IBM) und Quarks.

Das Project Eirini

Bei „Eirini“ handelt es sich um einen Backend-Scheduler zum Steuern von für Diego und Kubernetes. Eirini macht sich die Cloud-Controller API (CAPI) zu Nutze, um die die Aufgaben der Orchestrierung von der CF-Kontrollebene zu abstrahieren. So kann Eirini jeden Scheduler ansprechen, ob Diego, Kubernetes oder Docker Swarm, solange die Zielplattform über eine OPI-Implementierung verfügt. Eirini kann u.a. Diego-Laufzeitanweisungen für Kubernetes übersetzen und so die Bereitstellung von CF-Anwendungen mithilfe von OCI-Images ermöglichen.

Bei OCI handelt es sich um einen Standard der Open Containers Initiative, die ursprünglich unter anderem das Unternehmen Docker initiierte. Das Besondere an OCI ist das Konzept von Long Running Processes (LRPs) und die Zuweisung von Tasks zu Orchestrierern. (Im Übrigen: Dockers aktuelle Turbulenzen dürften auf die Überlebensfähigkeit der darauf basierenden Software keinerlei Auswirkungen haben auch wenn sich der Eigentümer ändern sollte.)

Das Project Quarks

Das „Project Quarks“ zielt darauf ab, die Cloud Foundry Application Runtime in Containern, statt in virtuellen Maschinen zu verpacken. Der resultierende containerisierte CFAR bietet eine mit BOSH-verwalteten CF-Installationen identische Entwicklererfahrung, stellt geringere Kapazitätsanforderungen an die Infrastruktur und bietet eine Ausführungsumgebung, mit der die Kubernetes-Nutzer bereits vertraut sind.

Die Containerisierungsinitiative von Cloud Foundry fokussiert auf die Umwandlung des Release-Manifests, den typischerweise BOSH zur Bereitstellung von Software nutzt, in Docker-Images und Helm-Charts zur Bereitstellung in Kubernetes. Das Verfahren, getauft auf die Bezeichnung „Fissle“ (aus dem Schottischen: ein raschelndes Geräusch), verpackt die Cloud Foundry Application Runtime, also die althergebrachte PaaS-Lösung von CF, in Docker-Images unter Verwendung von „Helm“-Charts zur anschließenden Bereitstellung auf einem Kubernetes-Cluster.

Quarks konvertiert somit vorhandene BOSH-Releases in Docker-Images und entsprechende Helm-Charts zur Installation auf Kubernetes ohne die Provisionierung von VMs. Der Ansatz beschleunigt die Initialisierung von Anwendungen und reduziert ihren Fußabdruck zur Minimierung der Bereitstellungskosten.

Für CF-Anwender wie die Datev, die nach außen hin (in Public-Clouds) nicht skalieren wollen und stattdessen mit kurzfristig starren Kapazitäten der eigenen Infrastruktur vorliebnehmen müssen, liegen die Vorteile von Eirini und Quarks auf der Hand.

* Das Autorenduo Anna Kobylinska und Filipe Pereira Martins arbeiten für McKinley Denali Inc. (USA).

(ID:46164476)