Je elementarer die Cloud als Infrastruktur wird, desto vielfältiger werden die Variationen und Abhängigkeiten. Seit einiger Zeit hat sich für diesen Trend der Begriff Multicloud etabliert. Die Definitionen, was Multicloud eigentlich genau bedeutet, fallen jedoch teils weit auseinander. Nichtsdestotrotz sehen sich immer mehr IT-Abteilungen herausgefordert, das Management solcher heterogenen Cloudlandschaften zu optimieren. Ab wann man eigentlich von einer Multicloud sprechen kann, welche Herausforderungen ihr Management birgt und wie dieses sich durch das Konzept des Multicloud-Würfels vereinfachen ließe, diskutiert dieser Beitrag.

Multicloud ist vorprogrammiert
Egal ob IT-Verantwortliche eines Tages aufwachen und realisieren, dass sie mehrere Clouds im Einsatz haben, oder bewusst einen strategischen Ansatz fahren: Die Multicloud ist meistens schon da, bevor sich IT-Verantwortliche dem Thema gezielt zuwenden. Nicht selten entsteht eine Multicloud-Landschaft ganz von allein, beispielsweise durch einen Zusammenschluss oder eine Übernahme. Andere, meist größere Unternehmen wiederum, gewähren einzelnen Abteilungen große Autonomie über die Kaufentscheidungen ihrer IT und damit die Wahl einer Cloud. Dann wiederum gibt es das altbekannte Problem der Schatten-IT.

Darüber hinaus sind moderne Applikationen aufgrund ihrer vielfältigen Abhängigkeiten ohnehin bereits in der Multicloud angekommen. Ein Beispiel wäre eine Webapplikation die zum Beispiel in einem Container auf AWS ECS läuft (Systeminfrastruktur-Service), zur Authentisierung von Anwendern Microsoft Azure AD verwendet (Applikationsinfrastruktur-Service), mittels SAP-API den Standort des Kunden erhält (Softwareplattform-Service) und Wetterdaten von der IBM The Weather Channel API anzeigt (Informations-Service). Hier verlassen wir das klassische Verständnis von Multicloud als die Nutzung mehrerer Hyperscaler-Clouds und erweitern es um weitere Ebenen beziehungsweise Layer. Im Grunde lässt sich also sagen, dass jede Multicloud-Strategie einen gewachsenen Zustand nachträglich in geordnete Bahnen lenken soll.

Entwickler – Lost in (Cloud) Translation
Am Ende der Kette von Geschäftsentscheidern und IT-Verantwortlichen stehen die Cloudarchitekten, die DevOps-Teams oder Product Owner, die für die Ausführung der Managementvision verantwortlich sind. Doch auch sie verstehen Multicloud noch viel zu häufig als bloßes Verschieben von Applikationen oder Workloads zwischen verschiedenen Hyperscaler Clouds, beispielsweise über Container-Architektur. Gleichzeitig besitzen sie meist eine bestimmte Cloudheimat, mit der sie sich am besten auskennen.

Dabei erfordert selbst der effektive Betrieb einer Single-Cloud-Umgebung eine steile Lernkurve. Zwischen den unterschiedlichen Clouds wiederum bestehen fundamentale, "philosophische" Unterschiede. Um ein und dieselbe Aufgabe in der AWS oder der Google Cloud zu lösen, müssen Programmierer Schlüsselkonzepte von Grund auf neu lernen oder intelligent abstrahieren.

Die Wahl der jeweiligen Cloudservices und APIs für eine Applikation sollte deshalb eine sehr bewusste und informierte Entscheidung sein, die sich ebenfalls nur mit einem funktionierenden Multicloud-Management treffen lassen. Einer der teuersten Fehler bei modernen Cloudarchitekturen ist es, unbeabsichtigt in komplexe Multicloud-Setups hineinzurutschen, die eine unnötige Komplexität im Management der Compliance, Sicherheit, Performance und Kosten mit sich bringen.

Für das technische Management und die Verwaltung von komplexen Microservices-Architekturen gibt es Service-Mesh- und API-Management-Plattformen (zum Beispiel Istio, Linkerd, RapidAPI), auf die wir in diesem Artikel nicht tiefer eingehen.

ln/Silvio Kleesattel, Technology & Innovation Lead bei Skaylink