Drei Clouds machen dich nicht souverän

Kaum ein Konzept hat in den vergangenen Jahren einen vergleichbaren Aufstieg erlebt wie Multi-Cloud. Kaum eine Strategiepräsentation kommt ohne entsprechende Architekturdiagramme aus, auf denen Anwendungen, Daten und Plattformdienste über mehrere Anbieter verteilt werden. Die zugrundeliegende Botschaft ist dabei meist dieselbe: Wer seine Systeme nicht ausschließlich bei einem einzelnen Cloud-Anbieter betreibt, reduziert Abhängigkeiten, erhöht die Resilienz und stärkt die digitale Souveränität des Unternehmens.

Die Attraktivität dieser Argumentation ist nachvollziehbar. Schließlich haben die vergangenen Jahre eindrucksvoll gezeigt, welche Risiken entstehen können, wenn Unternehmen zentrale Teile ihrer digitalen Infrastruktur in die Hände weniger globaler Anbieter legen. Diskussionen über den Cloud Act, geopolitische Spannungen, regulatorische Anforderungen oder die zunehmende Konzentration technologischer Macht haben dazu geführt, dass die Frage nach strategischen Abhängigkeiten heute deutlich ernster genommen wird als noch vor wenigen Jahren.

Dennoch lohnt es sich, an dieser Stelle einen Schritt zurückzutreten und eine grundlegendere Frage zu stellen: Führt die Nutzung mehrerer Cloud-Anbieter tatsächlich zu mehr digitaler Souveränität oder verwechseln wir hier möglicherweise zwei Konzepte, die zwar miteinander verwandt sind, aber keineswegs dasselbe beschreiben?

Denn bei genauerer Betrachtung zeigt sich, dass ein erheblicher Teil der Multi-Cloud-Debatte auf einer Annahme basiert, die selten explizit ausgesprochen wird. Nämlich auf der Vorstellung, dass die Anzahl der genutzten Anbieter in direktem Zusammenhang mit dem Grad der technologischen Unabhängigkeit eines Unternehmens steht.

Genau diese Annahme verdient eine kritische Betrachtung.

Die Verwechslung von Infrastruktur und Abhängigkeit

Wenn Unternehmen über Lock-in sprechen, richtet sich der Blick häufig auf die Infrastruktur selbst. Man möchte nicht vollständig von AWS abhängig sein. Man möchte nicht sämtliche Systeme ausschließlich auf Azure betreiben. Man möchte vermeiden, dass die eigene IT-Landschaft durch die Entscheidungen eines einzelnen Anbieters bestimmt wird.

Diese Überlegung ist grundsätzlich nachvollziehbar. Sie greift jedoch häufig zu kurz, weil sie den Ort der eigentlichen Abhängigkeit falsch identifiziert.

Die Bindungswirkung moderner Cloud-Plattformen entsteht längst nicht mehr primär durch virtuelle Maschinen, Netzwerksegmente oder Objektspeicher. Diese Komponenten sind weitgehend standardisiert und technisch vergleichsweise austauschbar. Die eigentliche Kopplung entsteht dort, wo Anwendungen beginnen, tief mit den spezifischen Diensten einer Plattform zu interagieren.

Identity- und Access-Management-Systeme, proprietäre Datenbankdienste, Messaging-Plattformen, Analytics-Services, KI-Angebote oder serverlose Laufzeitumgebungen bilden heute den eigentlichen Kern vieler Cloud-Architekturen. Je stärker Anwendungen auf diese Dienste zugeschnitten werden, desto schwieriger wird es, sie unabhängig vom jeweiligen Anbieter weiterzuentwickeln oder zu migrieren.

Die entscheidende Frage lautet deshalb nicht, auf wie vielen Clouds eine Anwendung betrieben wird. Die entscheidende Frage lautet vielmehr, welche Bestandteile der Anwendung unmittelbar von den proprietären Fähigkeiten einer bestimmten Plattform abhängig sind.

Ein Unternehmen kann Workloads gleichzeitig bei AWS, Azure und Google Cloud betreiben und dennoch hochgradig von den strategischen Entscheidungen dieser Anbieter abhängig sein. Umgekehrt kann eine Anwendung vollständig bei einem einzigen europäischen Provider laufen und gleichzeitig über eine Architektur verfügen, die einen Plattformwechsel mit überschaubarem Aufwand ermöglicht.

Die Anzahl der Anbieter beschreibt daher zunächst nur die Verteilung von Infrastruktur. Über den tatsächlichen Grad technologischer Handlungsfreiheit sagt sie erstaunlich wenig aus.

Warum zusätzliche Clouds nicht automatisch weniger Lock-in erzeugen

Besonders interessant wird die Diskussion dort, wo Multi-Cloud als Instrument zur Reduzierung von Lock-in verstanden wird.

Die zugrundeliegende Logik erscheint auf den ersten Blick schlüssig. Wenn die Abhängigkeit von einem Anbieter problematisch ist, müsste die Nutzung mehrerer Anbieter die Situation zwangsläufig verbessern.

Tatsächlich entsteht in vielen Fällen jedoch ein völlig anderer Effekt.

Anstatt ein proprietäres Ökosystem zu beherrschen, müssen Unternehmen plötzlich mehrere proprietäre Ökosysteme gleichzeitig verstehen, betreiben und absichern. Unterschiedliche Identitätsmodelle, unterschiedliche Sicherheitskonzepte, unterschiedliche Automatisierungswerkzeuge, unterschiedliche Netzwerkarchitekturen und unterschiedliche Betriebsparadigmen erhöhen die Komplexität erheblich. Mit jeder zusätzlichen Plattform wächst nicht nur die Anzahl der verfügbaren Optionen, sondern auch die Anzahl der Abhängigkeiten, die dauerhaft gemanagt werden müssen.

Die entscheidende Frage lautet deshalb nicht, ob mehrere Anbieter vorhanden sind. Die entscheidende Frage lautet, ob die zugrundeliegende Architektur tatsächlich in der Lage ist, zwischen diesen Anbietern zu wechseln.

Genau an dieser Stelle zeigt sich häufig eine bemerkenswerte Diskrepanz zwischen Theorie und Praxis. Viele Multi-Cloud-Landschaften verteilen Workloads über mehrere Plattformen, ohne die Portabilität der Anwendungen selbst wesentlich zu erhöhen. Die Systeme laufen zwar in unterschiedlichen Umgebungen, bleiben jedoch weiterhin eng mit den jeweiligen Plattformdiensten verknüpft. Die Folge ist eine Situation, in der die Anzahl der Anbieter steigt, ohne dass sich die tatsächliche technologische Bewegungsfreiheit in gleichem Maße verbessert.

Anders formuliert: Die Diversifizierung von Infrastruktur ist nicht automatisch gleichbedeutend mit der Diversifizierung von Abhängigkeiten.

Warum Kubernetes allein keine Souveränität schafft

An dieser Stelle wird häufig auf Kubernetes verwiesen. Und tatsächlich hat Kubernetes die Diskussion über Portabilität erheblich verändert.

Erstmals steht Unternehmen eine Plattform zur Verfügung, die Anwendungen weitgehend unabhängig von der zugrundeliegenden Infrastruktur betreiben kann. Ob ein Cluster in einem europäischen Rechenzentrum, in einer Public Cloud oder auf eigener Hardware ausgeführt wird, spielt für viele Workloads nur noch eine untergeordnete Rolle. Genau deshalb gilt Kubernetes heute für viele Organisationen als technische Grundlage digitaler Souveränität.

Allerdings entsteht auch hier häufig eine Verkürzung der eigentlichen Problematik.

Kubernetes löst in erster Linie die Portabilität von Workloads. Es löst nicht automatisch die Portabilität der gesamten Plattform.

Wer seine Anwendungen zwar containerisiert betreibt, gleichzeitig jedoch auf proprietäre Datenbanken, proprietäre Messaging-Systeme, proprietäre KI-Dienste oder proprietäre Identitätsplattformen setzt, reduziert lediglich einen Teil seiner Abhängigkeiten. Die Infrastruktur wird austauschbarer, die darüberliegenden Plattformdienste bleiben es jedoch häufig nicht.

Die eigentliche Herausforderung besteht daher nicht darin, Kubernetes einzuführen. Die eigentliche Herausforderung besteht darin, bewusst zu entscheiden, an welchen Stellen einer Architektur Portabilität strategisch erforderlich ist und an welchen Stellen eine Abhängigkeit akzeptiert werden kann, weil ihr Nutzen die damit verbundenen Risiken rechtfertigt.

Die Frage, die in vielen Strategien fehlt

Auffällig ist, dass Multi-Cloud-Initiativen häufig mit einer Diskussion über Anbieter beginnen, obwohl die wesentlich relevantere Fragestellung häufig unbeantwortet bleibt.

Bevor entschieden werden kann, ob Anwendungen über mehrere Plattformen verteilt werden sollten, müsste zunächst geklärt werden, welche Bestandteile der eigenen IT-Landschaft überhaupt einem relevanten Souveränitätsrisiko unterliegen und welche Konsequenzen ein Verlust technologischer Handlungsfreiheit in diesen Bereichen tatsächlich hätte.

Die Antwort darauf fällt selten pauschal aus.

Nicht jede Datenbank stellt automatisch eine strategische Abhängigkeit dar. Nicht jede Fachanwendung benötigt die Fähigkeit, innerhalb weniger Wochen auf eine alternative Plattform migriert werden zu können. Ebenso wenig ist jede Nutzung proprietärer Dienste per Definition problematisch. Die Vorstellung, digitale Souveränität verlange die vollständige Vermeidung sämtlicher Abhängigkeiten, wäre weder wirtschaftlich noch technisch sinnvoll.

Entscheidend ist vielmehr die Fähigkeit, zwischen akzeptablen und kritischen Abhängigkeiten unterscheiden zu können. Eine bewusst eingegangene Bindung an einen spezialisierten Dienst kann durchaus sinnvoll sein, sofern die damit verbundenen Konsequenzen verstanden und in die langfristige Architekturplanung einbezogen werden. Problematisch werden Abhängigkeiten erst dann, wenn sie ungeplant entstehen oder ihre Tragweite erst sichtbar wird, sobald regulatorische Veränderungen, wirtschaftliche Zwänge oder geopolitische Entwicklungen bereits Handlungsdruck erzeugen.

Digitale Souveränität beschreibt deshalb weniger den Zustand vollständiger Unabhängigkeit als vielmehr die Fähigkeit, technologische Abhängigkeiten transparent zu verstehen, aktiv zu steuern und dort Handlungsalternativen vorzuhalten, wo deren Verlust zu einem geschäftlichen Risiko werden würde.

Die eigentliche Herausforderung

Die Vorstellung, digitale Souveränität lasse sich primär durch die Verteilung von Anwendungen auf mehrere Cloud-Anbieter erreichen, greift daher zu kurz. Sie konzentriert sich auf die sichtbare Infrastruktur und blendet die deutlich relevanteren Architekturentscheidungen aus, die oberhalb dieser Infrastruktur getroffen werden.

Für Unternehmen ist deshalb häufig nicht die Frage entscheidend, ob sie eine, zwei oder drei Clouds nutzen. Entscheidend ist vielmehr, ob ihre Anwendungen, Daten und Betriebsmodelle so gestaltet sind, dass sie auch dann handlungsfähig bleiben, wenn sich Anbieterstrategien, regulatorische Rahmenbedingungen oder geopolitische Realitäten verändern.

Genau dort beginnt digitale Souveränität. Nicht bei der Anzahl der Logos in einem Architekturdiagramm, sondern bei der Fähigkeit eines Unternehmens, die Kontrolle über seine technologischen Optionen langfristig zu bewahren.

Digitale Souveränität ist kein Produkt und keine Beschaffungsentscheidung. Sie ist das Ergebnis bewusster Architekturentscheidungen. Genau dabei unterstützen wir Unternehmen bei ayedo – mit offenen Plattformen, cloud-nativen Technologien und einem klaren Fokus auf langfristige technologische Handlungsfähigkeit.