3. August 2021 von Marcus Peters
Cloud Native, Multi Cloud oder doch lieber Cloud Agnostic?
Die Motivation für IT-Verantwortliche Anwendungen, neudeutsch „Workloads“, in der Cloud zu betreiben, wird immer wieder heiß diskutiert. Auf der Haben-Seite werden dann oft Aspekte wie ein Wegfall der Verwaltung von Infrastrukturkomponenten, Möglichkeiten der Skalierung bei Last oder Reduktion der Betriebskosten genannt. Mittlerweile hat sich allerdings gezeigt, dass diese Argumente nicht pauschal haltbar sind und dass das Rechenzentrum in den Wolken professionell ausgesteuert werden muss, um die gewünschten Vorteile zu erbringen.
Unstrittig ist, dass Cloud-Technologien für die meisten Unternehmen in die Digitalisierungsstrategie gehören, da die Anforderungen an die IT an vielen Stellen eben doch flexibler und leistungsfähiger aus der Cloud als aus dem eigenen Rechenzentrum umgesetzt werden können. Natürlich ebenfalls nicht pauschal, sondern unter Berücksichtigung von Sicherheitsaspekten und Hybrid-Szenarien.
Oft wird der erste Schritt in die Cloud über die Verlagerung von virtuellen Maschinen in die Cloud-Infrastruktur getätigt. Dieses Vorgehen wird auch als „Lift and Shift“ bezeichnet. Und genau hier fängt es an, interessant zu werden: Bleibt die Organisation in dieser Phase stecken, ist der Spaß an der Cloud nur mäßig groß. Zwar fällt das Verwalten der Hardware weg, aber alle anderen Elemente vom Betriebssystem über Laufzeitkomponenten und Persistenzmechanismen bis zur Applikation selbst, müssen weiterhin organisiert und gepflegt werden.
Wie war das nochmal mit Cloud Native?
Die Cloud Native Computing Foundation definiert Cloud-Native-Technologien wie folgt:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.”
Demnach gilt eine Anwendung als „nativ“, wenn sie die Mechanismen zur Abstraktion von Betriebssystem, Laufzeit oder Persistenz nutzt und damit eben nicht in einer virtuellen Maschine läuft. Im Falle einer typischen Webanwendung mit einer Datenbank zur Speicherung von Daten könnten entsprechende Services des Cloudproviders den Webserver sowie die Datenbank ersetzen. Ein Beispiel für eine Überführung in diesen Zustand zeigt die folgende Abbildung.
Beispielhafte Transformation einer Webapplikation zu Cloud Native über „Refactoring“
Erst die Nutzung der Services des Cloudproviders entfaltet somit die volle Leistungsfähigkeit der Cloud.
Ein typischer Kritikpunkt eines derartigen Ansatzes ist die Bindung an einen Cloudprovider. Sobald eine Anwendung nativ in die Umgebung des Providers eingebunden ist, entsteht eine Abhängigkeit zu eben diesem Provider und damit der viel zitierte „Vendor Lock-in“.
Es lohnt sich allerdings, diesen Punkt etwas detaillierter zu betrachten: Je näher eine Cloud-Applikation an die darunter liegenden Schichten des Providers „gebunden“ ist, also native Zugriffe auf die Services erfolgen, desto optimierter läuft diese Anwendung bei und mit diesem Provider. Als Analogie dient hier der Rechner unter dem Schreibtisch. Einer Applikation, die für ein ausgewähltes Betriebssystem optimiert ist, steht die volle Leistungsfähigkeit des Systems zur Verfügung. Allerdings geht diese Leistungsfähigkeit zulasten der Portierbarkeit auf ein anderes Betriebssystem.
Um dies zu umgehen wird dann – wie bei Software, die auf verschiedenen Betriebssystemen lauffähig ist – oft von Multi-Cloud-Ansätzen gesprochen.
Und was macht Multi-Cloud?
Multi-Cloud bedeutet, wie der Name suggeriert, die Entscheidung Hyperscaler verschiedener Hersteller einzusetzen. In den meisten Fällen werden zwei Szenarien abgebildet: Entweder entscheidet sich das Unternehmen für jeden Workload, je nach Situation, einen anderen Cloud-Anbieter auszuwählen. Oder ein Workload wird über eine Abstraktion der Cloud-Services auf verschiedene Cloudprovider verteilt.
Der erste Fall ist recht einfach überlegt und folgt typischen Strategien zu Diversifizierung des Lieferantenpools. Kaum ein Unternehmen hat heute die gesamte Software von einem Hersteller und das ist auch gut so. So kann es sinnvoll sein, auch bei der Auswahl von Cloud-Diensten neben einer Plattformstrategie einzelne Services mit einem „Best of Breed“-Ansatz auszuwählen, um direkt Kosten zu sparen oder gewinne zu maximieren.
Damit läuft die einzelne Applikation dann aber trotzdem auf genau einem Hyperscaler. Und für diese gilt dann wieder das oben gesagte zum Ausreizen der Leistungsfähigkeit über Cloud-Native-Ansätze.
Cloud Agnostic – Eine Anwendung gleichzeitig auf verschiedenen Clouds laufen lassen
Wer sich ganz vom Cloudprovider entkoppeln möchte, dem bleibt nur der Ansatz Cloud-agnostisch vorzugehen. Damit läuft die Applikation gleichzeitig auf verschiedenen Hyperscalern oder kann in den typischen Redundanzszenarien auf Cold-, Warm- und Hot-Standby verteilt werden.
Diese Freiheit schafft allerdings Komplexität und ist nicht zu unterschätzen. Ein naheliegender Ansatz ist eine Verteilung über Container. Diese sind für die jeweilige Cloud-Umgebung optimiert und entsprechende Komponenten sind von vielen Herstellen verfügbar. Neben dem von Forrester in der „Forrester Wave“ als Marktführer gewählten Lösung „Red Hat OpenShift“ stellen auch Microsoft, Google und AWS entsprechende Mechanismen bereit. Die folgende Abbildung zeigt ein Architekturbeispiel für die Verwaltung einer Multi-Cloud-Umgebung mit Microsofts Azure Arc.
Multi-Cloud mit Azure Arc, Quelle: Microsoft.com
Allerdings müssen dieser Ansatz und die Motivation dahinter im Detail betrachtet werden. Nicht jede Anwendung ist pauschal für jedes Container-Szenario aller Cloudprovider geeignet. Unterschiede in der zugrunde liegenden Rechen- oder Netzwerkinfrastruktur sowie die Nähe zu abhängigen Diensten können zu einer erheblich unterschiedlichen Leistung führen. Das Verschieben einer Applikation zwischen Cloud-Umgebungen könnte auch das Verschieben von Daten erfordern. Neben wirtschaftlichen Parametern unterscheiden sich die Umgebungen häufig in den Diensten und Einrichtungen, die sie zum Speichern und Verwalten dieser Daten bereitstellen.
Ein anderer Ansatz für Cloud Agnostic, neben dem Verteilen über Container, ist die Einarbeitung einer Abstraktionsschicht, die Kommunikation und Verhalten der Cloudprovider zusammenfasst. Dies zeigt die folgende Abbildung.
Multi-Cloud-Szenario mit einem Abstraktionsmechanismus
Dieser Ansatz schafft die Möglichkeit, die Anwendung über eine Abstraktionsschicht mit folgender nativer Kopplung an die Services der Cloudprovider verteilt zu betreiben. Allerdings sind die Aufwände dies zu erreichen am höchsten und es ist wie beim Verteilen über Container nicht sichergestellt, dass aus allen Clouds auch das letzte Fünkchen Leistung herausgeholt wird.
Fazit
Eine Multi-Cloud-Strategie kann – wenn gut überlegt – eine sinnvolle Alternative zu „alles aus einer Hand“ darstellen. Hierbei gilt es aber gut zu hinterfragen, was denn genau erreicht werden soll und ob es wirklich erforderlich ist, dass eine Anwendung Cloud-agnostisch auf verschiedenen Clouds läuft. Oder ob es nicht auch einfacher geht und für jeweils eine Anwendung ein Zuhause in der Cloud definiert wird. In letzterem Fall bietet es sich dann an, für die jeweiligen Applikationen Cloud-Native-Ansätze zu betrachten, um eben die volle Leistungsfähigkeit auszuschöpfen.
