Wie stark bist du von der cloud-basierten Infrastruktur abhängig? Eine Multicloud-Bewertung für IT-Führungskräfte

Was dir diese Bewertung bei der Beurteilung hilft

Wichtigste Erkenntnis: Diese Bewertung schätzt ein, wie groß dein Risiko ist. Das Ergebnis ist ein kurzer Überblick darüber, welche Teile deines Stacks einer möglicherweise notwendigen Änderung widerstehen würden. Die Punktzahl dient als Grundlage für interne Gespräche, um konkrete Entscheidungen anzustoßen.

Dies ist ein Arbeitsblatt, das abschätzt, inwieweit deine aktuelle cloud-Konfiguration einer Änderung widerstehen würde, die du möglicherweise tatsächlich vornehmen musst: eine neue Region für einen regulierten Kunden, eine Migration zur Umsetzung einer Preisverhandlung oder eine Umstellung auf einen alternativen Anbieter nach einem Ausfall. 

Das Ergebnis ist eine kurze Übersicht über die Risiken, die du in eine Arbeitssitzung einbringen kannst. Die Verringerung dieser Art von Anbieterabhängigkeit ist mittlerweile auch zu einer regulatorischen Priorität geworden: Der EU-Datenschutzgesetzentwurf verlangt nun von cloud-Anbietern, Hindernisse beim Wechsel zwischen Diensten zu beseitigen, und die internationale Norm ISO/IEC 19941 definiert herstellerneutral, wie cloud-Portabilität und Interoperabilität funktionieren sollten.
 

Die vier Bereiche von Multicloud-Risiken

Die cloud-basierte Abhängigkeit konzentriert sich in der Regel auf vier Bereiche. Bewerte jeden Bereich für sich; eine kombinierte Bewertung verschleiert, wo das eigentliche Risiko liegt.

1. Anbieterabhängigkeit. Wie stark ist deine Anwendung an die Dienste, das Identitätsmodell oder proprietäre Grundelemente eines Anbieters gebunden?
2. Migrationsaufwand. Wie lange würde ein geplanter Wechsel zu einem anderen unterstützten Anbieter tatsächlich dauern? Stunden, Tage, Wochen oder ist das unklar?
3. Inkonsistenz bei den Arbeitsabläufen. Verwenden deine Teams über alle Anbieter hinweg denselben Bereitstellungs-Workflow oder gibt es je nach cloud unterschiedliche Vorgehensweisen?
4. Governance-Lücken. Sind deine Audit-Kontrollen, Geheimnisse und Zugriffsregeln anbieterübergreifend übertragbar oder sind sie an die jeweilige Konsole gebunden?
    

Bewerten Sie Ihren aktuellen Stand

Vergebe für jeden Bereich eine Punktzahl von 0 bis 3.

• 0 „Stark“: übertragbar, dokumentiert, Nachweise auf Anfrage verfügbar.
• 1 Teilweise: grundsätzlich übertragbar, aber langsam oder unzureichend dokumentiert.
• 2 Schwach: Es ist erheblicher Aufwand erforderlich, um etwas zu ändern; es ist „Stammeswissen“ im Spiel.
• 3 Gefährdet: Veränderungen werden durch strukturelle Entscheidungen blockiert, die du nicht schnell rückgängig machen kannst.

Nutze diese Fragen, um die jeweilige Punktzahl zu vergeben:

1. Anbieterabhängigkeit: Wenn du dich morgen für einen anderen Anbieter entscheiden müsstest, wie viel Prozent deines Stacks müsstest du neu aufbauen?
2. Migrationsaufwand: Wie schnell könntet ihr eure Daten und Workloads von Grund auf zu einem anderen cloud-Anbieter übertragen?
3. Inkonsistenz der Arbeitsabläufe: Verwenden deine Teams bei jedem Anbieter dieselben Bereitstellungsschritte und Werkzeuge, oder ändert sich der Prozess je nachdem, welche cloud sie nutzen?
4. Governance-Lücken: Kannst du mit einer einzigen Abfrage Audit-Nachweise für eine Workload über mehrere Anbieter hinweg erstellen?

Eine Gesamtpunktzahl von 0 bis 4 ist gut. 5 bis 8 bedeutet, dass es echte Risiken gibt, an denen man arbeiten sollte. 9 bis 12 bedeutet, dass die Abhängigkeit dein Betriebsmodell geprägt hat.

Buche eine Multicloud-Bewertung 

So sehen risikoreiche Muster aus

Drei Muster sind zuverlässige Anzeichen für ein hohes Risiko:

• Eine CI/CD-Pipeline pro cloud für dieselbe Workload. Selbst wenn das heute noch funktioniert, verdoppelt sich dadurch deine operative Angriffsfläche und Abweichungen sind vorprogrammiert.
• Audit-Nachweise wurden manuell aus mehreren Konsolen rekonstruiert. Die Zeit bis zum Vorliegen von Nachweisen ist ein verlässlicher Indikator für Governance-Schulden.
• Ein Plattformteam, das nach Anbieter-Expertise aufgeteilt ist. Wenn das Team nach clouds aufgeteilt ist, gilt das auch für die Workloads.

Wenn eines dieser Muster vorliegt und dauerhaft besteht, erreichst du in mindestens einem Bereich eine Bewertung von 2 oder 3. Sind zwei Muster vorhanden, potenziert sich das Risiko.
 

So sieht eine Verbesserung normalerweise aus

Verbesserungsmaßnahmen sind kleiner, als man erwartet. Drei Änderungen machen den größten Teil der Risikominderung aus:

• Eine einzige Anwendungsdefinition, die in Git committet ist und ohne Neuprogrammierung auf jeden unterstützten Anbieter abzielt. Das ist die Grundlage; ohne sie bringen die anderen Maßnahmen weniger.
• Richtlinien, die als Code definiert und auf der Plattformebene angewendet werden. Die Governance bleibt cloudübergreifend einheitlich, sodass sich die Audit-Zyklen verkürzen.
• Ein einheitlicher Bereitstellungs-Workflow über alle Teams hinweg. Entwickler müssen keine neue Pipeline erlernen, wenn sich das Bereitstellungsziel ändert.

Upsun basiert auf diesem Modell und unterstützt AWS, Azure, Google Cloud, IBM Cloud und OVHcloud von einer einzigen Plattform aus.
 

Was du als Nächstes intern prüfen solltest

Nimm deine beiden Bereiche mit der höchsten Punktzahl mit in eine 30-minütige Arbeitssitzung mit dem Team, das für die Workload verantwortlich ist. Stell drei Fragen: Welche Entscheidung hat diese Schwachstelle dauerhaft gemacht? Wie müsste eine Änderung aussehen? Was kostet es, wenn man den Zustand noch weitere zwölf Monate so belässt?

Die Antworten werden meist schon während der Sitzung klar. Der schwierige Teil ist die Entscheidung, ob man handelt.

Lies das Migrations-Playbook: Wie du dich ohne Unterbrechungen aus der Bindung befreist 

Häufig gestellte Fragen (FAQs)

Was ist Cloud-Abhängigkeit?

Cloud-Abhängigkeit ist der Grad, in dem deine Anwendungen, Abläufe und Governance an einen bestimmten Cloud-Anbieter gebunden sind. Sie zeigt sich in Form von Diensten, die sich nicht ohne Weiteres verlagern lassen, Workflows, die nur in einer Cloud funktionieren, und Prüfnachweisen, die nur eine einzige Konsole liefern kann. Je höher die Abhängigkeit, desto langsamer und teurer werden Änderungen.

Wie misst man das Risiko einer Anbieterabhängigkeit?

Das Risiko lässt sich anhand von vier Bereichen messen: Anbieterabhängigkeit (wie eng die Anwendung an die Dienste eines Anbieters gebunden ist), Migrationshürden (wie lange eine geplante Umstellung dauern würde), Inkonsistenz der Arbeitsabläufe (ob Teams über verschiedene clouds hinweg denselben Workflow nutzen) und Governance-Lücken (ob Kontrollmechanismen übertragbar sind). Bewerte jeden Bereich auf einer Skala von 0 bis 3, um zu erkennen, wo sich das Risiko konzentriert.

Was sind die Anzeichen für ein hohes Cloud-Risiko?

Drei Anzeichen deuten zuverlässig auf ein hohes Risiko hin: die Pflege einer CI/CD-Pipeline pro cloud für dieselbe Arbeitslast, die manuelle Rekonstruktion von Audit-Nachweisen aus mehreren Konsolen und ein Plattformteam, das nach Anbieter-Fachwissen aufgeteilt ist. Jeder einzelne Punkt ist ein Problem, das es zu beheben gilt. Zwei davon zusammen verstärken das Risiko schneller als jede einzelne architektonische Entscheidung.

Kannst du die cloud-Abhängigkeit reduzieren, ohne den Anbieter zu wechseln?

Ja. Der größte Teil der Reduzierung der cloud-Abhängigkeit ergibt sich aus Änderungen auf der Bereitstellungsebene. Eine portable Anwendungsdefinition, die programmiert wurde, und Richtlinien, die als Code deklariert sind, sowie ein einziger Bereitstellungs-Workflow verringern die Abhängigkeit, ohne dass eine Migration erforderlich ist. Die Wahl des Anbieters wird zu einer nachgelagerten Entscheidung, sobald die Bereitstellungsebene konsolidiert ist.

Wie reduzierst du das Multicloud-Risiko in der Praxis?

Drei Änderungen machen den größten Teil der Reduzierung des Multicloud-Risikos aus: eine portable Anwendungsdefinition, die in Git festgehalten wird, als Code deklarierte Richtlinien, die auf der Plattformebene angewendet werden, und ein einziger Bereitstellungs-Workflow, unabhängig von der Ziel-Cloud. Die erste Änderung ist die Grundlage; ohne sie bringen die anderen weniger.