Ein praktischer Leitfaden zur Integration der App-Bereitstellung in ein Multicloud-Betriebsmodell

Wo Multicloud-Betriebsmodelle normalerweise scheitern

Wichtigste Erkenntnis: Verschiedene Teams arbeiten in unterschiedlichen clouds, jedes Team entwickelt seine eigene Pipeline und sein eigenes Runbook, und die Fragmentierung zeigt sich später in Form von verpassten Terminen und langwierigen Audits. Bis dahin hat sich die „Betriebsmodell-Schuld“ bereits seit Monaten angehäuft.

Die meisten Multicloud-Probleme zeigen sich im Betrieb und entstehen selten als Teil eines Plans. Ein Team stellt auf AWS bereit. Ein anderes wählt Google Cloud für ein neues Produkt. Eine Übernahme bringt Azure mit sich. Ein regulierter Kunde schreibt eine bestimmte Region bei einem vierten Anbieter vor. Keine dieser Entscheidungen ist für sich genommen falsch.

Das Problem ist, was sich um sie herum ansammelt. Jede Anwendung kommt mit ihrer eigenen Pipeline, ihrem eigenen Observability-Stack, ihrem eigenen Audit-Prozess und ihrem eigenen Runbook für den Bereitschaftsdienst. Am Ende betreibt das Unternehmen ein Anwendungsportfolio, das sich über mehrere Anbieter erstreckt, wobei jede App in der cloud läuft, die zu diesem Zeitpunkt am besten passte, und für jede eine eigene Arbeitsweise gilt.

Der doppelte Aufwand kostet mehr als die cloud-Rechnung. Der Zusammenbruch entsteht, weil die ursprüngliche Entscheidung auf Kapazität optimiert war (welche cloud diese Workload hosten sollte) und die Bereitstellung (wie sie aufgebaut, bereitgestellt, gesteuert und betrieben werden sollte) zu kurz gekommen ist. 

Sobald diese Zersplitterung einmal besteht, verstärkt jede neue Entscheidung sie noch. Eine weitere App bedeutet eine weitere Pipeline. Ein weiterer Anbieter bedeutet ein weiteres Runbook. Die Zersplitterung wächst still und leise, bis jemand versucht, sie zu prüfen, eine Workload zu verschieben oder ihre Kosten zu prognostizieren.

Die vier Dinge, die IT-Verantwortliche bewerten müssen

Eine sinnvolle Bewertung lässt sich auf vier Variablen reduzieren. Jede davon gilt unabhängig davon, ob du eine App über mehrere Clouds hinweg betreibst oder viele Apps, die auf verschiedene Anbieter verteilt sind. Für jede gibt es eine Frage, die du dir stellen musst, und ein klares Bild davon, wie ein gutes Ergebnis aussieht.

1. Portabilität: Wenn du eine Workload in eine andere unterstützte cloud verschieben müsstest, könntest du sie dann aus einem sauberen Git-Checkout neu bereitstellen, ohne sie neu schreiben zu müssen? „Gut“ bedeutet „Ja“, und zwar innerhalb eines dokumentierten Wiederherstellungsfensters. (Dies ist der Fall, in dem „dieselbe App bei einem anderen Anbieter“ eine Rolle spielt, und es ist ein Aspekt des Gesamtbildes, nicht das Ganze.)
2. Governance: Werden deine Audit-Kontrollen, Geheimnisse und Umgebungskonfigurationen sowie Zugriffsregeln einmalig definiert oder für jede cloud neu erstellt? „Gut“ bedeutet einmalig, angewendet auf der Plattformebene.
3. Konsistenz bei der Bereitstellung: Ändert sich der Workflow eines Entwicklers je nachdem, welche cloud er als Ziel wählt? „Gut“ bedeutet: Nein. Gleiches Git, gleiche Pipeline, gleiche Dashboards.
4. Operativer Aufwand: Benötigt dein Plattformteam für jeden Anbieter separate Fähigkeiten, Runbooks oder Rotationspläne? Gut bedeutet: ein Team, ein Workflow, der cloudübergreifend angewendet wird.

Diese vier Variablen entscheiden darüber, ob Multicloud ein Kontrollinstrument oder ein Treiber für Unübersichtlichkeit ist.

Anzeichen dafür, dass dein aktuelles Modell zur Unübersichtlichkeit beiträgt

Einige Muster sind verlässliche Warnsignale. Jedes einzelne davon lässt sich beheben. Zwei oder mehr zusammen deuten auf ein strukturelles Problem hin:

• Separate CI/CD-Pipelines, die pro Anbieter erstellt und angepasst werden – selbst für Anwendungen, die ähnliche Aufgaben erfüllen.
• Audit-Zyklen, die länger dauern, weil Nachweise aus mehreren Konsolen abgerufen und manuell abgeglichen werden müssen.
• Ein und dieselbe Art von Deployment verhält sich in Cloud A anders als in Cloud B, ohne dass jemand erklären kann, warum.
• Plattformteams pro Anbieter oder Bereitschaftsdienste pro Anbieter.
• Kostenprognosen, für die separate Cloud-Rechnungen manuell zusammengefügt werden müssen.

Hol dir den praktischen Leitfaden, wie du die Anwendungsbereitstellung in ein Multicloud-Betriebsmodell einbindest. 

So sieht ein übersichtlicheres Multicloud-Betriebsmodell aus

Das Wichtigste auf einen Blick: Ein übersichtlicheres Modell behandelt Anbieter als austauschbare Bereitstellungsziele unter einer einzigen Bereitstellungsschicht. Eine Anwendungsdefinition, ein Satz von Richtlinien, ein Workflow und ein Observability-Stack erstrecken sich über alle clouds. 

Ein einheitliches Modell behandelt den cloud-Anbieter als Bereitstellungsziel unter einer einzigen Bereitstellungsschicht. Die Anwendung wird einmal definiert, die Richtlinien werden einmal festgelegt, und der Workflow bleibt derselbe, unabhängig davon, wo die Workload ausgeführt wird. So sieht Multicloud-Kontrolle in der Praxis aus.

Konkret bedeutet das:

• Eine Anwendungsdefinition (in Git committet) zielt auf AWS, Azure, Google Cloud, IBM oder OVHcloud ab, ohne dass eine Neuprogrammierung nötig ist.
• Ein Satz von Governance-Kontrollen, einschließlich Identitäten, Geheimnissen, Netzwerkrichtlinien und Compliance-Status, gilt auf der Plattformebene.
• Ein einziger Bereitstellungs-Workflow bietet jedem Entwickler dieselbe Pipeline, unabhängig vom Ziel.
• Ein Observability-Stack und eine Kostenübersicht erstrecken sich über alle Anbieter hinweg.

Upsun basiert auf diesem Modell.

Schneller Selbsttest: Wo stehst du heute?

Das Wichtigste zum Mitnehmen: Wenn die meisten Antworten „Nein“ lauten, liegt der Schwerpunkt der Arbeit auf der Bereitstellungsschicht.

Fünf Fragen. Beantworte sie ehrlich:

1. Kannst du deine kritischste Workload von einem sauberen Git-Checkout aus in einer anderen unterstützten cloud neu bereitstellen?
2. Sind deine Governance-Kontrollen als Programmierung deklariert, am selben Ort wie die Anwendung?
3. Ist der Workflow eines Entwicklers identisch, unabhängig davon, welche cloud er als Ziel wählt?
4. Erhältst du einheitliche Audit-Nachweise über alle Anbieter hinweg, ohne separate Konsolen manuell abgleichen zu müssen?
5. Arbeitet dein Bereitschaftsteam anhand eines einzigen Runbooks für diese Workload?

Drei oder mehr „Nein“-Antworten bedeuten, dass das Betriebsmodell der Engpass ist. Die Reibungspunkte liegen darin, wie Workloads erstellt, bereitgestellt und verwaltet werden – daher bleiben sie bestehen, egal wie viele Anbieter du nutzt. Die Reduzierung der Anbieteranzahl kann das Problem kurzfristig lindern, aber die Unübersichtlichkeit kehrt mit der nächsten App oder Übernahme zurück. Erst die Konsolidierung der Bereitstellungsschicht beseitigt das Problem an der Quelle.

Nächster Schritt

Wenn der Selbsttest mehr als zwei „Nein“-Antworten ergeben hat, ist es am sinnvollsten, gezielt zu prüfen, wo das Betriebsmodell in Bezug auf Nachvollziehbarkeit, Zeitaufwand oder Konsistenz Schwächen aufweist. Diese Überprüfung dauert ein paar Stunden und führt zu einem konkreten Plan zur Behebung der Probleme.

Buche eine Überprüfung des Multicloud-Betriebsmodells

Häufig gestellte Fragen (FAQs)

Was ist ein Multicloud-Betriebsmodell?

Ein Multicloud-Betriebsmodell ist die Gesamtheit der Vorgehensweisen, Tools und Richtlinien, die regeln, wie ein Unternehmen Anwendungen über mehrere cloud-Anbieter hinweg entwickelt, bereitstellt, verwaltet und betreibt. Ein kohärentes Modell betrachtet die Wahl des Anbieters als eine Entscheidung zur Bereitstellung und sorgt für konsistente Bereitstellung und Governance, unabhängig davon, in welcher cloud die Workload läuft.

Was ist Multicloud-Wildwuchs?

Multicloud-Wildwuchs ist die schrittweise Fragmentierung von Bereitstellung, Governance und Betrieb über verschiedene cloud-Anbieter hinweg. Er entsteht, wenn Teams ihre eigenen Pipelines, Runbooks und Audit-Prozesse entwickeln und sich die Unterschiede zwischen ihnen mit der Zeit vergrößern. Das Ergebnis sind Doppelarbeit, langsamere Audits und ein Bereitstellungsmodell, das sich umso schwerer konsolidieren lässt, je länger es bestehen bleibt.

Was bedeutet Konsistenz bei der Bereitstellung in einer Multicloud-Umgebung?

Konsistenz bei der Bereitstellung bedeutet, dass der Arbeitsablauf eines Entwicklers immer gleich bleibt, egal in welcher cloud die Workload ausgeführt wird. Dieselbe Git-Pipeline, dieselben Dashboards, dieselben Bereitstellungsschritte. Ohne diese Konsistenz pflegen Teams für jede cloud einen separaten Bereitstellungsprozess, was den betrieblichen Aufwand erhöht und das Risiko von anbieter-spezifischen Abweichungen vergrößert. Laut der DORA-Studie „State of DevOps“ führen konsistente und automatisierte Bereitstellungspraktiken zu besseren Unternehmensergebnissen in Bezug auf Bereitstellungshäufigkeit, Fehlerquote bei Änderungen und Wiederherstellungszeit.

Wie sieht eine gute Multicloud-Governance aus?

Gute Multicloud-Governance wendet auf der Plattformebene bei jedem Anbieter dieselben Kontrollen an (Zugriff, Identität, Geheimnisse, Netzwerk und Compliance-Status). Die Kontrollen werden einmalig programmiert, zusammen mit der Anwendung festgeschrieben und begleiten die Workload, egal wo sie ausgeführt wird. Auditoren sehen einheitliche Nachweise, und Teams verfügen über eine einzige Quelle der Wahrheit.

Solltest du die Anzahl der Anbieter reduzieren oder die Bereitstellungsschicht konsolidieren?

Die Konsolidierung der Bereitstellungsschicht bringt fast immer mehr Nutzen als die Reduzierung der Anbieter. Das Hinzufügen oder Entfernen von Clouds löst nicht die Reibungsverluste bei der Erstellung, Steuerung und dem Betrieb von Workloads. Eine einzige, einheitliche Bereitstellungsschicht reduziert diese Reibungsverluste an der Quelle, unabhängig davon, wie viele Anbieter darunter liegen.