Suchen

Cloud-agnostische Softwareentwicklung, Teil 1 Gründe für Cloud Foundry

| Autor / Redakteur: Filipe Martins & Anna Kobylinska * / Stephan Augsten

Das gefürchtete Phänomen des Vendor-Lock-In macht den Entwicklern in verteilten Cloud-Anwendungen zu schaffen. Die Echtzeit-Portabilität von Code zwischen Ausführungsumgebungen verschiedener Anbieter wird dank Lösungen wie Cloud Foundry dennoch Realität.

Das CloudFoundry-Projekt trat von San Francisco aus seinen Siegeszug über den Globus an.
Das CloudFoundry-Projekt trat von San Francisco aus seinen Siegeszug über den Globus an.
(Bild gemeinfrei: Jared Erondu / Unsplash)

Mit der Hybridisierung der Unternehmens-IT geht ein wachsendes Bedürfnis nach Cloud-agnostischer Anwendungsbereitstellung einher. Nach dem massiven Sprung in die Cloud wollen auch deutsche Unternehmen das Potenzial voll ausloten.

Im Cloud Monitor 2019, einer Studie des Branchenverbands Bitkom im Auftrag von KPMG, zeigt sich ein „deutlicher Anstieg“ der Cloud-Nutzung bei Unternehmen in Deutschland. Bereits drei Viertel der Befragten sind mit ihren Anwendungen in der Wolke. Der Anteil der Nutzer wuchs von 65 Prozent (2016) über ziemlich genau zwei Drittel (2017) auf nun satte 73 Prozent in 2018.

Reibungslos ging es aber nicht vonstatten: In nahezu jedem zweiten Unternehmen (43 Prozent) kam es aufgrund technischer Probleme seitens eines Cloud-Providers zu Betriebsausfällen. Nur knapp jeder dritte Cloud-Nutzer (32 Prozent) konnte die Anwendungsbereitstellung ohne Betriebsausfälle umsetzen. Gerade einmal jedes zehnte Unternehmen konnte daraufhin die SLAs mit den Anbietern nachverhandeln.

Ein CloudFoundry Summit bietet die Gelegenheit, Gleichgesinnte zu treffen.
Ein CloudFoundry Summit bietet die Gelegenheit, Gleichgesinnte zu treffen.
(Bild: Cloud Foundry)

Eine kaum sichtbare Minderheit von gerade einmal drei Prozent der Betroffenen habe es geschafft, eine Multi-Cloud-Strategie zur Bereitstellung ihrer Dienste auf die Beine zu stellen. Offenbar haben die meisten noch nichts von Cloud Foundry gehört.

Das jähe Ende von OpenStack

Solides Wachstum: Deutsche Unternehmen geben Privaten Clouds den Vorzug vor Public Clouds.
Solides Wachstum: Deutsche Unternehmen geben Privaten Clouds den Vorzug vor Public Clouds.
(Bild: KPMG / Bitkom)

Ohnehin ist in Deutschland ist die Begeisterung für die Anwendungsbereitstellung in der Public Cloud eher verhalten. Die Nutzung von Public-Clouds ist laut dem Cloud Monitor 2019 nur von 29 Prozent auf 35 Prozent, also um sechs Prozentpunkte gewachsen. Die Gründe hierfür dürften unter anderem in Datenschutz-Bedenken liegen.

Die drei führenden Anbieter von Public Clouds – Amazon AWS, Google Compute Cloud und Microsoft Azure – haben die Konformität mit der DSGVO anfangs verschlafen. Gerade dieses Feature war laut der Bitkom/KPMG-Studie bei 90 Prozent aller befragten Unternehmen ein Top-Kriterium für die Wahl der Ausführungsumgebung. Brauchbare DSGVO-Lösungen trudelten erst gut ein Jahr später nach dem Stichtag (dem 25. Mai 2018) ein. Das war den Cloud-Nutzern offenbar zu spät.

Gut zwei Drittel der Befragten erwarten zudem von ihrem Cloud-Anbieter einen „Hauptsitz im Rechtsgebiet der EU“. Die jeweilige EU-Zentrale empfängt ja offenbar aus Sicht der Befragten nur bindende Vorgaben und „vorgekaute“ Entscheidungen aus Übersee. Mit einem Hauptsitz in der EU kann nun wirklich keiner der großen Cloud-Betreiber punkten. Deutsche Cloud-Anwender scheint dieser Umstand zu stören.

Apache CloudStack sollte die Erstellung von privaten wie auch öffentlichen Clouds auf unternehmenseigener Infrastruktur ermöglichen, sei es als die primäre Laufzeitumgebung für virtualisierte Anwendungsbereitstellung oder als ein Fallback. Das Projekt liegt in den letzten Zügen.

Ein Blick auf die globale IT-Landschaft enthüllt zwar eine lange Liste von Public Cloud-Providern mit OpenStack-Unterstützung, doch hierbei handelt es sich vor allem um Nischenanbieter. Auch sind in der OpenStack-Gemeinde viele namhafte Unternehmen und Organisationen mit dabei – dazu zählt unter anderem der eine oder andere Telekom-Dienstanbieter.

Jedoch nutzen die meisten Beteiligten das quelloffene Framework lediglich In-House in Eigenregie. So ist die OpenStack-Landschaft stark fragmentiert. Nennenswerte Anbieter von Public-Cloud-Diensten auf OpenStack-Basis, die es mit den globalen Schwergewichten aufnehmen könnten, gibt es nicht mehr.

SUSE streicht die OpenStack-Segel zugunsten von Cloud Foundry

Sogar SUSE, ein Platinum-Sponsor der OpenStack Foundation, hat kalte Füße bekommen. Der einstige Vorzeigeanwender hat die eigene OpenStack Cloud eingestellt. Als Abschiedsgeschenk gibt es mit SUSE OpenStack Cloud 9 noch eine letzte Hauptversion für bestehende Nutzer zum Tränen abwischen.

Im Inneren der SUSE Cloud Application Platform schlägt inzwischen die CFAR, eine Laufzeitumgebung von Cloud Foundry (Cloud Foundry Application Runtime). Diese ermöglicht die Bereitstellung von Code in beliebigen Programmiersprachen, aus beliebigen Entwicklungsframeworks auf beliebiger Cloud-Infrastruktur einschließlich OpenStack.

Vorerst bleibt SUSE noch weiterhin ein Platinum-Level-Sponsor der OpenStack-Foundation und Alan Clark behält seinen Sitz im Vorstand der Stiftung. Doch das Sponsoring von SUSE, bisher auf dem höchsten verfügbaren Level, dürfte in naher Zukunft einer kleineren Mitgliedschaft weichen. Die OpenStack-Bannerträger hatten sich ganz klar erhofft, mit OpenStack ein Gegengewicht zu AWS, Azure und Google Cloud zu bilden.

Doch das gefürchtete Vendor-Lock-In greift nun auch in der Cloud immer stärker um sich und wurmt ganz besonders Entwickler dezentralisierter Anwendungen. Niemand möchte das sprichwörtliche Rad neu erfinden (spricht: den Code für eine andere Cloud umschreiben), wenn es sich vermeiden lässt.

(Nicht mehr) hilflos zuschauen: Unternehmen erleiden Ausfallzeiten ihrer Cloud-Lösungen durch das Versagen ihrer Cloud-Anbieter, ziehen daraus jedoch im Nachhinein keine Konsequenzen. Ob sie nicht wissen, dass es geht?
(Nicht mehr) hilflos zuschauen: Unternehmen erleiden Ausfallzeiten ihrer Cloud-Lösungen durch das Versagen ihrer Cloud-Anbieter, ziehen daraus jedoch im Nachhinein keine Konsequenzen. Ob sie nicht wissen, dass es geht?
(Bild: KPMG / Bitkom)

Dies zeigt sich auch ganz deutlich in den Zahlen des Cloud-Monitors: Nur ein Prozent der Unternehmen, die in den vergangenen 12 Monaten von einem Ausfall der Infrastruktur ihres Cloud-Anbieters betroffen waren, haben den Cloud-Provider gewechselt. Cloud Foundry, der Hoffnungsträger Cloud-agnostischer Softwareentwicklung, verspricht – und leistet – Abhilfe.

Mit Cloud Foundry zur Cloud-Portabilität verteilter Anwendungen

Cloud Foundry (kurz: CF) ist eine quelloffene „as-a-Service“-Plattform (PaaS) von Pivotal für die Cloud-agnostische Bereitstellung von Microservice-Anwendungen. Cloud Foundry abstrahiert die Infrastruktur, um die Portabilität von unverändertem Anwendungscode zwischen den Clouds verschiedener Anbieter zu gewährleisten.

CF-optimierte Anwendungen lassen sich zwischen On-Premises, öffentlichen Clouds und verwalteten Infrastrukturen unverändert hin und her migrieren, notfalls in Nahezu-Echtzeit. Die Plattform unterstützt OpenStack als einen von derzeit zehn Infrastrukturanbietern. Dazu zählen neben AWS, Microsoft Azure, Google Cloud Platform unter anderem auch VMware vSphere und Photon OS, IBM Cloud und RackHD von Dell EMC.

Für die Integration von Cloud Foundry mit den verschiedenen Infrastrukturanbietern zeichnet ein Toolchain namens BOSH mit seinen modularen Schnittstellen verantwortlich. BOSH setzt sich aus einem Server namens „BOSH Director“ und einem CLI-Werkzeug zusammen. Unter Verwendung des passenden CPI (Cloud Provider Interface) kann BOSH sowohl VMs als auch Container auf dem Infrastrukturunterbau der jeweiligen Cloud orchestrieren.

Auf diese Wiese befreit Cloud Foundry den Nutzer vom Vendor-Lock-In an den Cloud-Betreiber. Eine andere CPI „hineinstecken“ und schon ist die Anwendung in wenigen Minuten hinweg migriert. Die Cloud-Foundry-tTrategie zielt darauf ab, die Entwicklererfahrung möglichst stressfrei zu gestalten.

Cloud Foundry vollzieht die „Cloudifizierung“ der Anwendungsbereitstellung auf eine „entwicklerfreundliche“ Art und Weise, nämlich auf dem Unterbau beliebiger IaaS-Dienste.
Cloud Foundry vollzieht die „Cloudifizierung“ der Anwendungsbereitstellung auf eine „entwicklerfreundliche“ Art und Weise, nämlich auf dem Unterbau beliebiger IaaS-Dienste.
(Bild: Cloud Foundry)

Onsi Fakhouri, Senior Vice President, R&D für die Cloud bei Pivotal, hat seinerzeit den Ansatz auf einem Cloud Foundry Summit wie folgt zusammengefasst: „Hier ist mein Code. Lasse ihn bitte in der Cloud laufen. Egal, wie“. Die Bemerkung bringt die Idee von Cloud Foundry aus Entwicklersicht doch ganz gut auf den Punkt.

Vor nicht allzu langer Zeit wurde es auf einem CF-Workshop recht offensichtlich. Statt an einer längeren Vorführung der Fähigkeiten von Cloud Foundry teilzunehmen, wollten die Zuschauer doch lieber über die IT-Transformation und die DevOps-Kultur diskutieren. Die kurze Demo des übersichtlichen Befehlssatzes habe der überwiegenden Mehrheit bereits zum Verständnis gereicht, hieß es.

Flache Lernkurve: Die Architektur der CloudFoundry-Plattform in einer übersichtlichen Darstellung verbirgt die Komplexität der vielen Zusammenhänge. OpenStack ist hier aus Versehen gleicht doppelt vertreten.
Flache Lernkurve: Die Architektur der CloudFoundry-Plattform in einer übersichtlichen Darstellung verbirgt die Komplexität der vielen Zusammenhänge. OpenStack ist hier aus Versehen gleicht doppelt vertreten.
(Bild: Cloud Foundry)

Cloud Foundry versteckt die Komplexitäten des Infrastruktur-Unterbaus, provisioniert bedarfsgerecht die benötigten Ressourcen und automatisiert die Bereitstellung der Anwendung samt aller Abhängigkeiten. BOSH koordiniert hierbei das Verpacken, das Bereitstellen und die Verwaltung von Cloud-Anwendungen während ihrer gesamten Lebenszeit. Kurz auf den Punkt gebracht: Luxus.

Die Bereitstellung von Anwendungen in Cloud Foundry erfolgt mit Hilfe der sogenannten Buildpacks. Bei Buildpacks handelt es sich um Skripte, welche die betreffenden Anwendungen fein säuberlich als sogenannte Droplets ausgeben. Ist in der Umgebung ein anwendungsgerechtes Buildpack vorhanden, reicht übrigens ein einfacher cf-Push aus, und die Bereitstellung wird voll funktionsfähig „ausgerollt“.

Entwicklern steht natürlich die Möglichkeit offen, eigene Buildpacks zu erstellen, welche den spezifischen Anforderungen ihrer betreffenden Anwendungsarchitekturen punktgenau gerecht werden. Wem das alles zu kompliziert erscheint, der kann immerhin auch einfach Docker-Container orchestrieren.

Fazit

Neben Pivotal haben im Übrigen auch SAP, IBM und die Swisscom ganz offiziell eigene Distributionen von CloudFoundry im Köcher. Die Tage von OpenStack scheinen offenbar gezählt zu sein. Verbranntes Kind scheut das Feuer und so zieht es die betroffenen „Devs“ nun verstärkt hin zu CloudFoundry, der Cloud-agnostischen „as-a-Service“-Plattform.

Für die Entwickler verteilter Cloud-Anwendungen stellt sich die berechtigte Frage, wie sie ihren Code für die neue Umgebung fit machen, um im Falle eines Falles in den vollen Genuss verzögerungsfreier Code-Portabilität zu kommen. In dem zweiten Teil dieser Folge geht es eben darum, durch Konformität mit gewissen Design-Prinzipien völlig Cloud-agnostische Anwendungen ins Leben zu rufen.

(ID:46226611)