Herausforderungen beim Umstieg auf eine Multicloud-Strategie

Hybrid- oder Multi-Cloud-Strategien werden von Unternehmen aus einer Vielzahl von Gründen eingesetzt, von rechtlichen Gründen bis hin zu Kosteneinsparungen und Anwendungsflexibilität. Häufig möchten Unternehmen die Flexibilität haben, die besten Preise oder Funktionen verschiedener Public-Cloud-Anbieter zu nutzen. Die Vermeidung von Anbieterabhängigkeit ist ein weiterer Grund, warum ein Unternehmen eine Multi-Cloud-Strategie anstrebt.

Während ein Unternehmen möglicherweise nicht auf unbestimmte Zeit an einen Cloud-Anbieter gebunden sein möchte, ist der Wechsel zu einer Multi-Cloud-Strategie nicht für jeden geeignet. Tatsächlich ist das Risiko, an einen Cloud-Anbieter gebunden zu sein, nicht unbedingt das Risiko, als das es oft wahrgenommen wird.

Dieser Artikel beleuchtet, warum der Wechsel zu einer Multi-Cloud-Strategie nicht jedermanns Sache ist, und welche Hindernisse und Herausforderungen zu überwinden sind, wenn diese Option in Betracht gezogen wird.

Nicht alle Wolken sind gleich

Theoretisch kann eine Anwendung über mehrere Cloud-Provider-Umgebungen verteilt werden, aber „True Application Portability“ beinhaltet Hindernisse, die überwunden werden müssen, bevor die Anwendung portabel oder wirklich Multi-Cloud-fähig wird.

Erstens müssen virtuelle Maschinen (VMs) aus der Anwendungsarchitektur eliminiert werden. Unter der Decke sind nicht alle Wolken gleich. Jede Cloud hat ihre eigene zugrunde liegende Abstraktionsschicht, die oft als Cloud Service Fabric bezeichnet wird. Hier werden Netzwerk, Rechenleistung und Speicher der VM präsentiert, die normalerweise zum Hosten von Anwendungen verwendet wird. Beispielsweise unterscheidet sich AWS Networking erheblich von Microsoft Azure Networking und damit sowohl AWS als auch Azure Networking unterscheiden sich in ihrer Einrichtung erheblich von GCP Networking. Dasselbe gilt für virtuelle Maschinen, eine auf Azure ausgeführte VM kann nicht automatisch zu AWS verschoben werden und eine AWS-VM kann nicht direkt zu GCP verschoben werden.

Wenn eine VM zu einem neuen Cloud-Anbieter verschoben werden soll, muss das VM-Image geändert werden, damit es mit der Cloud-Fabric der zugrunde liegenden Zielplattform übereinstimmt. Rechen- und Speicherangebote unterscheiden sich zwischen Cloud-Anbietern und bieten oft ihre eigenen Herausforderungen in Bezug auf die Portabilität von Anwendungen. Diese Probleme werden noch verstärkt, wenn die Anwendung Platform-as-a-Service (PaaS)-Angebote verwendet, beispielsweise Database-as-a-Service (DBaaS), WebApps oder Message-Broker-Komponenten, bei denen die zugrunde liegenden Datenspeicherelemente, Website-Bereitstellungsmechanismen und Anwendungslogik sind Eigentum dieses bestimmten Cloud-Angebots.

Wenn die Anwendung Functions-as-a-Service (FaaS) verwendet (Cloud-Dienste, die eine automatisierte Plattform bereitstellen, die es Kunden ermöglicht, Anwendungsfunktionen zu entwickeln, auszuführen und zu verwalten, ohne die Komplexität des Aufbaus und der Wartung der Infrastruktur selbst), dann wird die Aufgabe der Portabilität sogar noch komplexer, da die FaaS-Nuancen jeder Cloud wiederum spezifisch für den Cloud-Anbieter sind.

Aber wenn VMs, PaaS und (serverlose) FaaS-Architekturen nicht verfügbar sind, was kann ein Entwickler tun?

Aufschlüsselung der Multi-Cloud-Herausforderung

Dieses Interoperabilitätsproblem zwischen Clouds kann als das Problem angesehen werden, das ein internationaler Reisender hat, wenn er seinen Laptop in mehreren verschiedenen Ländern aufladen möchte. Sie haben entweder einen Stecker für jedes Stromsystem (also einen für Großbritannien, einen für Europa und einen für die USA) oder einen Adapter, der überall funktioniert.

Für die Anwendungsarchitektur wäre dieser Adapter ein Produkt wie Docker, ein Container-Framework, das unabhängig von der Cloud, auf der es sich befindet, dasselbe ist. Die Containerisierung einer vorhandenen Anwendung ist jedoch nicht unbedingt einfach oder kostengünstig. Container sind eine leichtgewichtige Hosting-Architektur, die darauf ausgelegt ist, schnell hoch- und herunterzufahren und so zu skalieren, dass sie die Ressourcen direkt an die Nachfrage anpassen. Container ermöglichen es Ihnen, am wenigsten zu bezahlen und gleichzeitig das Beste aus Ihrer Cloud bereitzustellen. Je schwerer ein Behälter ist, desto weniger tragbar ist er.

Herausforderung eins: Eine Anwendung in Microservices herunterbrechen

Um Container im großen Maßstab in jeder Cloud ausführen zu können, müssen Sie die Anwendung zunächst in kleine Komponenten, sogenannte Microservices, aufteilen. Jeder Microservice verfügt über einen eigenen Container. Microservices sind diskrete Funktionen innerhalb einer Anwendung, die zusammengenommen dem Benutzer eine größere, komplexere Anwendung präsentieren. Wenn wir uns beispielsweise eine einfache E-Commerce-Anwendung mit einer Website, einer Datenbank, die Kundenpräferenzen speichert, einem Katalog der zum Verkauf stehenden Waren und einer Zahlungsfunktion ansehen, wären in ihrer Architektur mindestens vier Mikrodienste erforderlich. Wenn Sie dann Zahlungsbenachrichtigungen und Fulfillment-Nachrichten an ein Lager hinzufügen würden, um die Waren zu liefern, würden Sie mindestens sechs Microservices benötigen. Und so geht es weiter. Jede neue Anwendungsfunktion erfordert eigene Servicekomponenten.

Es ist teuer und zeitaufwändig, eine vorhandene Anwendung in eine auf Microservices basierende Architektur zu zerlegen. Dies ist jedoch eine Voraussetzung für die Anwendungsportabilität, da der Container der universelle Adapter ist.

Herausforderung zwei: Anwenden eines Orchestrators zum Ausführen von containerisierten Anwendungen

Leider hört die Geschichte hier nicht auf. Um eine komplexe containerisierte Anwendung auszuführen, benötigen Sie eine wesentliche Komponente – einen Orchestrator – der Ihre Container überwacht und verwaltet. Der Orchestrator versteht die gesamte Microservices-Architektur, einschließlich der Container und wie viele davon eine bestimmte Anwendung bilden. Es kann jedem Container mitteilen, wo sich die anderen Container befinden, die zur Bereitstellung der Anwendung verwendet werden. Der gebräuchlichste Orchestrator für die containerisierte Anwendungsbereitstellung ist Kubernetes, dessen Betrieb recht komplex ist.

Die Aufteilung der Anwendung in Microservices ist der größte Blocker, um Multi-Cloud-fähig zu werden. Sie vermeiden möglicherweise die Abhängigkeit von einem einzigen Cloud-Anbieter, aber Sie werden sich immer noch an Docker und denjenigen, der die Kubernetes-Funktionen bereitstellt, die Sie zur Orchestrierung Ihrer auf Microservices basierenden Anwendung nutzen, „eingebunden“ fühlen. Anbieterbindung auf einer bestimmten Ebene ist leider eine Tatsache des Lebens, Sie müssen nur entscheiden, auf welcher Ebene diese Bindung stattfinden soll.

Herausforderung drei: Es ist äußerst schwierig, die Abhängigkeit von Cloud-Anbietern zu vermeiden

Wenn Ihnen die Kosten am Herzen liegen, müssen Sie PaaS- oder FaaS-Funktionen innerhalb der Cloud nutzen. Obwohl diese beiden Dienste zwar billiger zu betreiben sind, erhöhen sie jedoch Ihre Bindung an den von Ihnen gewählten Cloud-Anbieter. Wenn Sie sich auf FaaS oder PaaS verlassen und der Anbieter beschließt, diese Dienste einzustellen oder zu ändern, sind Sie wiederum gezwungen, die darauf basierenden Dienste zu überarbeiten. Sie sind sowohl in den Upgrade-Zyklus des Anbieters als auch in dessen Technologie eingeschlossen!

Sofern Ihre Anwendung nicht bereits auf Microservices basiert, wird der Neuentwicklungsaufwand alle Kosteneinsparungen durch die Verwendung eines einzelnen Cloud-Anbieters bei weitem aufwiegen. Wenn es sich um eine kommerzielle Softwareanwendung von der Stange handelt, sind Sie außerdem völlig der Gnade des Softwareanbieters ausgeliefert, wann oder ob er jemals beabsichtigt, die Software in eine auf Microservices basierende Architektur umzuwandeln, die für Containerisierung und Kubernetes-Bereitstellung geeignet ist.

Verwenden einer Cloud, die für jede Workload am besten geeignet ist

Die meisten heute verwendeten Multi-Cloud-Strategien beinhalten nicht das Dehnen einer einzelnen Anwendung über mehrere Clouds (siehe oben). Es ist viel besser, sich darauf zu konzentrieren, die Stärken und Kostenvorteile der Ausführung der Workloads zu nutzen, die am besten auf diese Cloud abgestimmt sind. Wenn Sie beispielsweise Ihre eigene Software erstellen, indem Sie Open-Source-Funktionen mit einer DevOps-Basis zusammenfügen, werden Sie diese Workload wahrscheinlich auf AWS ausführen. Wenn Sie große Mengen an Rechenleistung benötigen, um wissenschaftliche oder statistische Modelle auszuführen, werden Sie dies wahrscheinlich auf der GCP tun, oder wenn Sie Bedenken hinsichtlich der Gewährleistung der Informationssicherheit haben, können Sie diese ausführen Microsoft Azurblau. (Haftungsausschluss: Jeder der genannten Cloud-Anbieter wird gerne näher erläutern, warum sein Bereich der Cloud für jede der oben genannten Workloads super-wunderbar ist – die stereotypen Bezeichnungen verschwimmen mit zunehmender Leistungsfähigkeit – obwohl…).

Es gibt drei wichtige Überlegungen, die Sie anstellen sollten, bevor Sie Ihren Cloud-Service verschieben.

1. Die Vermeidung von Ausfallzeiten ist ein wichtiger Aspekt

Viele anbieterspezifische Dienste werden von einzelnen Regionen innerhalb einer Cloud bereitgestellt, aber mehreren Regionen präsentiert, als ob sie in dieser Region nativ wären. Einige hochkarätige AWS- und Azure-Ausfälle in letzter Zeit wurden auf spezifische Ausfälle in einem oder zwei Rechenzentren in den USA zurückgeführt – seien Sie vorsichtig, auf welche Dienste und Regionen Sie sich verlassen. Zentralisiertes DNS und Authentifizierung sind das Lebenselixier von Anwendungen, daher sollten Sie für diese kritischen Dienste Resilienz einbauen. Zu beachten ist, dass Hyper-Scaler-Ausfälle selten sind und wenn sie auftreten, werden sie oft viel schneller behoben als herkömmliche IT-Ausfälle in einem lokalen Rechenzentrum. Wenn ein Ausfall mehrere Kunden betrifft, können Sie garantieren, dass der Cloud-Anbieter analysiert, wie der Ausfall begann und wie verhindert werden kann, dass er erneut auftritt, was häufig Investitionen bedeutet, um den Dienst widerstandsfähiger zu machen.

2. Machen Sie Architekturen und Anwendungen geografisch widerstandsfähig

Die verteilte Nutzung von Diensten sollte von mindestens zwei regionalen Rechenzentren bereitgestellt werden, um die Daten in der Nähe des Verbrauchsorts zu halten und die Latenz für die Benutzer zu reduzieren. Alle Hyperscale-Cloud-Anbieter haben eine gute regionale Aufteilung der Rechenzentren, daher ist dies nicht unbedingt ein Grund für eine Multi-Vendor-Cloud-Strategie, sondern einfach eine bewährte Methode, um einen Ausfall in einem einzelnen Rechenzentrum zu vermeiden, der alle Benutzer in dieser Region betrifft .

3. Die Sicherung mehrerer Clouds ist immer weitaus komplexer als die Sicherung einer Cloud-Architektur eines einzelnen Anbieters.

Nutzen Sie CIS (Center for Internet Security)-Benchmarks für Cyber-Resilience, verwenden Sie Multi-Faktor-Authentifizierung, und wenn Sie in die Cloud wechseln, haben Sie ein SIEM-System, das überwacht, was in jeder Umgebung in einer Konsole passiert. Wenn Sie keinen Echtzeit-Einblick in Ihre Umgebung haben, ist es schwierig, nach verdächtigen Aktivitäten zu suchen, und Sie werden niemals einen Angriff erkennen, während er stattfindet. Das bedeutet, dass der angerichtete Schaden immer deutlich höher ist, als wenn Sie die Dinge in Echtzeit überwachen würden. Letztendlich wachsen öffentliche und Multi-Cloud-Umgebungen für die Überwachung und Verwaltung über den menschlichen Maßstab hinaus. Hier ermöglichen Cloud-agnostisches Application Resource Management (ARM), Advanced Observability und Extended Detection and Response (XDR)-Systeme, die durch künstliche Intelligenz angetrieben werden, die automatisierte Optimierung, Behebung und den Schutz, die manuelle menschliche Bemühungen niemals erreichen werden.

Zusammenfassend

Ich würde immer empfehlen, dass eine Organisation mit einem einzelnen Cloud-Anbieter beginnt und sich in der Nutzung der nativen Tools und Dienste dieses Anbieters auskennt. Wenn dann die Nutzung der Cloud im Unternehmen ausgereift ist und alle Aspekte des Betriebs und der Nutzung der Fähigkeiten dieses Cloud-Anbieters gemeistert wurden, kann es beginnen zu beurteilen, welche wirklichen Vorteile durch den Wechsel zu einer Multi-Cloud-Strategie erzielt werden können. Versuchen Sie nicht, den Ozean zum Kochen zu bringen – es ist besser, ein Experte für jede Wolke zu sein, als ein Generalist für mehrere Wolken. Für Multi-Cloud-Strategien sind Toolsets von Drittanbietern erforderlich, aber native Toolsets von Anbietern verfügen normalerweise über einen umfassenderen Funktionsumfang für die Cloud-Funktionen dieses Anbieters.