Sind Container der Weg zu Cloud-agnostischen Workloads?

Was bedeutet Cloud-agnostisch?

Cloud-agnostisch ist ein etwas diffuser Begriff. Er bedeutet nicht, dass eine Organisation oder ein IT-Team keine präferierte Cloud-Plattform hat. Er bezieht sich auch nicht speziell auf eine Sammlung von Hardware, auf der jede Cloud-Plattform laufen kann.

Cloud-Agnostizismus hat viel mehr mit den Workloads zu tun: es bedeutet, dass ein Workload auf jeder verfügbaren Cloud-Plattform implementiert und zwischen diesen verschoben werden kann. Wirtschaftliche Faktoren zwingen Unternehmen dazu, zu evaluieren, ob sie bestimmte Workloads aus kostenintensiven Umgebungen in kostengünstigere verschieben können, zum Beispiel, wenn diese Workloads nicht die hohe Leistung der teureren Umgebung benötigen. Das bedeutet aber oft, dass mehr als eine Cloud im Einsatz sein muss.

Multi-Cloud versus Cloud-agnostisch

Viele Unternehmen befinden sich bereits in der Lage, Multi-Clouds zu betreiben. Das heißt, sie hosten Workloads verteilt auf verschiedene Cloud-Anbieter. Diese Workloads sind in der Folge jedoch abhängig vom jeweiligen Anbieter, zum Beispiel AWS oder Microsoft Azure und lassen sich nicht einfach auf die Google Cloud oder IBM Cloud migrieren. Dieses Multi-Cloud-Setup ist somit nicht automatisch Cloud-agnostisch, da jeder Workload an seinen jeweiligen Cloud-Host gebunden ist und sich nicht frei zwischen den Anbietern verschieben lässt.

Theoretisch wäre eine Cloud-agnostische Umgebung für Administratoren einfacher zu verwalten als eine bloße Multi-Cloud-Umgebung. Mit einer einzigen, standardisierten Verwaltungsschnittstelle könnte der Betrieb jeden einzelnen Workload überwachen und Berichte über ihn einsehen, egal wo er sich befindet. In einer Multi-Cloud-Umgebung mit nicht-agnostischen Workloads müssen IT-Admins Informationsfeeds aus heterogenen Systemen aggregieren, oft mit der Notwendigkeit, die Daten zu normalisieren und zusätzliche Analysen durchzuführen, bevor Mitarbeiter Einstellungen anpassen oder Probleme beheben können.

Probleme mit dem Cloud-Agnostizismus

Moderne Workloads haben viele Abhängigkeiten, die gemeinsame APIs und andere Standards für den Betrieb erfordern. Wären alle Cloud-Plattformen gleich, dann könnten IT-Teams wirklich agnostische Workloads erstellen, die ohne Probleme zwischen diesen Plattformen wechseln. Cloud-Anbieter befinden sich aber in einem Wettbewerb untereinander. Sie wollen nicht, dass ihre Plattform identisch mit einer anderen ist, sie wollen, dass sie besser ist, oder andere Services bietet. Ein Teil dieser Differenzierung erfolgt über Verfügbarkeitsstufen oder Verwaltungsmöglichkeiten, ein Großteil jedoch über die differenzierten Cloud-Services.

Wenn sich Unternehmen für eine Private- oder Public-Cloud-Plattform entscheiden und nicht-standardisierte Erweiterungen oder Services verwenden, ist der zugehörige Workload an die Cloud-Plattform gebunden und nicht mehr Cloud-agnostisch.

Container sind eine Chance für flexiblere Multi-Clouds

Aus den oben genannten Gründen – Differenzierung zwischen den Services und Plattformen der Cloud-Anbieter – war es schwierig, wenn nicht gar unmöglich, einen Cloud-agnostischen Workload zu erstellen, der sich nahtlos über die Umgebungen der Anbieter hinweg migrieren lässt. Aber die Standardisierung der Branche rund um die Container-Orchestrierung macht Cloud-agnostische Workloads zunehmend realistischer.

DevOps-Praktiken erfordern, dass Entwickler Container-Images in einer Entwicklungsumgebung erstellen und in die Betriebsumgebung übertragen können – mit minimalen Eingriffen. Ein Orchestrierungs-Tool kann Container verpacken, bereitstellen und aktualisieren. Dieses Tool stellt sicher, dass die benötigten Ressourcen virtuell zusammenkommen und nivelliert somit die Unterschiede zwischen physischer und virtueller Ebene einer Plattform. Systemadministratoren müssen sich somit nicht so intensiv wie bisher um die eigentliche Plattform selbst kümmern.

Kubernetes ist das derzeit populärste Programm für Container-Orchestrierung. AWS, Azure, Google Cloud Platform, IBM Cloud und viele andere Public Clouds unterstützen es. Einige Private-Cloud-Plattformen, wie Red Hat OpenShift und Oracles Private Cloud Appliance, bieten entweder integriertes Kubernetes oder erleichtern dessen Einsatz. Auch die meisten DevOps-Tools haben mittlerweile Kubernetes-Unterstützung eingebaut.

Ist Cloud-Agnostizismus also bald die Norm?

Mit Kubernetes als gemeinsamem Faktor über die meisten virtualisierten Plattformen hinweg – und mit Kubernetes selbst, das sich mit den Unwägbarkeiten der physischen und virtuellen Umgebungen auseinandersetzt – sollte die Portabilität von Workloads mittlerweile einfach sein, oder?

Leider nein.

Kubernetes schafft eine IT-Plattform, die nominell auf standardisierten Systemen basiert. Doch Cloud-Anbietern fügen dem jeweils ihre einzigartigen Erweiterungen und Modifikationen hinzu. Und diese nicht standardisierten Erweiterungen oder Dienste binden Workloads wie gehabt an bestimmte Cloud-Plattformen.

Selbst mit Kubernetes als gemeinsamer Basis sind keine zwei Distributionen identisch. So kann ein Administrator beispielsweise nicht das Kubernetes-Management-Dashboard eines Anbieters verwenden, um eine andere Kubernetes-Distribution zu verwalten. Jede Cloud-Plattform implementiert Kubernetes auf eine etwas andere Art und Weise und hat möglicherweise ein eigenes Dashboard, um diese spezifische Implementierung anzuzeigen und zu verwalten. Selbst wenn eine IT-Organisation ihr eigenes Kubernetes-Überwachungs-Dashboard hat, sind dem Grenzen gesetzt, weil Cloud-Anbieter beschränken, welche Datenströme eingespeist werden können. Infolgedessen benötigen Teams unter Umständen mehrere Dashboards.

Die IT muss außerdem ihre Orchestratoren orchestrieren um Cloud-agnostische Bereitstellungen wirklich praktikabel zu machen.

Sobald sich ein geeigneter Standard (wie Kubernetes) für eine Technologie herauskristallisiert, beschließen die Anbieter, diese zu unterstützen. Aber dann fügen sie einzigartige Funktionen hinzu, um sich vom Wettbewerb abzuheben – so dass ihre Version wieder vom Standard abweicht. Die feste Bindung der Kunden ist auch im Interesse der Cloud-Anbieter. Deshalb behindern sie den Datenfluss über Plattformgrenzen hinweg und machen eine übergreifende Lösung unmöglich.

Kubernetes hat zwar einen Cloud-agnostischen Ansatz theoretisch ermöglicht; Anbieter legen dem jedoch Steine in den Weg.

Es ist daher eher sinnvoll, eine Multi-Cloud-Umgebung so zu planen, dass sie optimale Managementsysteme bietet. Anwender sollten weiterhin stets Ausschau nach Verbesserungsmöglichkeiten und Innovationen halten. Suchen Sie nach einem Multi-Cloud-Management-Tool, das im Laufe der Zeit zusätzliche Funktionen hinzufügt, um sich der für Cloud-agnostische Operationen angestrebten zentrale Verwaltungsplattform offen zu halten.