Multi-Cloud-Management

"Multi-Cloud" wird oft als strategischer Begriff verwendet — ein Grund, sich von einem einzelnen Anbieter unabhängig zu machen, bessere Preise auszuhandeln oder eine Data-Residency-Anforderung zu erfüllen. Multi-Cloud-Management ist die engere, operative Ebene unter dieser Strategie: die Tools und Prozesse, mit denen ein Infrastrukturteam Workloads tatsächlich über mehrere Provider hinweg betreiben kann, ohne jeden einzelnen als separate Aufgabe zu behandeln. Ohne sie bedeutet "Multi-Cloud" in der Praxis: eine eigene Konsole, ein eigener Satz Zugangsdaten und eine eigene Terminologie für jeden Provider — und keine einzige Stelle, an der sich eine einfache Frage beantworten lässt: Welche Infrastruktur existiert gerade, und wer hat sie zuletzt geändert?

Jeder Provider bringt seine eigene Konsole, CLI, sein eigenes IAM-Modell und seine eigene Terminologie für dieselben zugrunde liegenden Primitive mit — eine virtuelle Maschine, eine Security Group, eine DNS-Zone, ein Storage-Volume. Genau diese Fragmentierung ist das eigentliche Problem, das Multi-Cloud-Management löst. Es beginnt mit der Discovery: Ein Provider-Konto wird verbunden, und sofort ist ein Inventar dessen sichtbar, was dort bereits läuft — bevor irgendetwas migriert oder geändert wird. Von dort aus wendet es einen einheitlichen Workflow auf gängige Lifecycle-Aktionen an — Provisionierung, Starten, Stoppen, Größenänderung, Löschen —, unabhängig davon, bei welchem Provider eine Ressource liegt. Die stärkeren Implementierungen verwalten die Konfiguration live und synchron direkt beim Provider, statt über eine zwischengespeicherte Kopie in einer eigenen Datenbank — sodass eine über das Tool vorgenommene Änderung dieselbe ist, die man beim Einloggen in die eigene Konsole des Providers sehen würde.

Multi-Cloud-Management reicht über den Compute-Lifecycle hinaus in die Bereiche des Betriebs, die tatsächlich ein Risiko darstellen, wenn sie zwischen Providern uneinheitlich sind. Zugriffskontrolle muss überall gleich funktionieren — Single Sign-On, rollenbasierte Berechtigungen und freigabepflichtige Rechteerweiterung für sensible Aktionen, statt eines je nach Provider unterschiedlichen Identitätsmodells. Jede Änderung muss zurückverfolgbar sein, weshalb ein Audit-Trail über alle verbundenen Provider hinweg hier stärker ins Gewicht fällt als in einer Single-Cloud-Umgebung — es ist der Unterschied zwischen einer beantwortbaren Frage und einer Untersuchung. Und weil Infrastrukturkosten zu den ersten Dingen gehören, die über mehrere Provider hinweg unübersichtlich werden, gehören Kostenübersicht und Anomalieerkennung an denselben Ort wie die Provisionierung — nicht in eine separate Tabelle, die einmal im Monat abgeglichen wird. Viele Teams betreiben außerdem Infrastruktur, die gar keine Cloud ist — On-Premise- oder Bare-Metal-Server — und erwarten, dass dieselbe Disziplin bei Monitoring und Patching auch dort gilt.