Die Abhängigkeit von einem einzigen Cloud-Anbieter galt lange Zeit als akzeptabler Kompromiss. Mittlerweile wird dies zunehmend als systemisches Risiko mit hohen Ausfallkosten betrachtet.
Das Problem zeigt sich nicht auf der Ebene von Latenz oder Durchsatz, sondern auf der Ebene der Kontrolle. Der europäische Cloud-Markt ist stark konzentriert: Etwa 70 % entfallen auf drei US-amerikanische Anbieter. Dabei beseitigt selbst die Speicherung von Daten in regionalen Rechenzentren nicht die rechtliche Abhängigkeit. Präzedenzfälle zeigen, dass der Zugang zu Diensten durch externe Faktoren eingeschränkt werden kann – durch Sanktionen oder physische Vorfälle. Die Wahrscheinlichkeit solcher Ereignisse bleibt gering, ist aber nicht mehr null. In Systemen mit hoher Abhängigkeit bedeutet dies einen plötzlichen und vollständigen Ausfall, keine bloße Degradation. Dies verändert die Risikoklasse: von einem operativen zu einem strategischen Risiko.
Als Antwort wird keine Isolation vorgeschlagen, sondern die Verringerung der Abhängigkeit durch architektonische Einschränkungen. Der erste Ansatz ist Multi-Cloud durch Standardisierung. Die Kernidee ist keine abstrakte Portabilität, sondern die Möglichkeit, den Anbieter mit minimaler Reibung zu wechseln. Dies wird durch De-facto-Standards erreicht: S3 API für Object Storage, Kubernetes für die Orchestrierung, Kafka-Protokoll für Streaming, Postgres Wire Protocol für Datenbanken. Der Kompromiss ist offensichtlich: Zunahme der operativen Komplexität, höhere Kosten und der Verzicht auf herstellerspezifische (vendor-specific) Funktionen. Es ist eine Bewegung hin zum „kleinsten gemeinsamen Nenner“. Aber die Alternative – ein strikter Vendor Lock-in – bietet ein schlechteres Risikoprofil.
Der zweite Ansatz sind Protokolle mit einem „Credible Exit“ am Beispiel des AT-Protokolls. Die Architektur ist so aufgebaut, dass der Nutzer den Anbieter ohne Verlust von Daten und Identität wechseln kann. Die Daten werden in persönlichen Repositories gespeichert, die auf einem Personal Data Server (PDS) gehostet werden. Die Aggregationsschicht (Relay) bildet einen Event-Stream, und die AppView erstellt Indizes. Die Komponenten können von verschiedenen Anbietern betrieben werden. Selbst das zentralisierte Element (Directory) ist kryptografisch geschützt und erlaubt Forks. Dies verschiebt die Kontrolle: Die Plattform ist nicht länger ein Blockadepunkt. Der Preis dafür ist ein komplexeres Konsensmodell und die Notwendigkeit, ein Protokoll anstelle eines geschlossenen Systems zu unterstützen.
Der dritte Ansatz ist die Local-First-Architektur. Hier wird die Source of Truth auf die Client-Seite verlagert. Die lokale Kopie der Daten wird zur primären Instanz, während die Cloud die Rolle der Synchronisation und des Backups übernimmt. Die technologische Basis bilden CRDTs (Conflict-free Replicated Data Types), die es ermöglichen, Änderungen ohne zentralen Koordinator abzugleichen. Die praktische Umsetzung, beispielsweise mit Automerge, zeigt, dass dieser Ansatz für Collaborative Editing funktioniert. Dies verringert die Abhängigkeit vom Zentrum und vereinfacht den Anbieterwechsel bis hin zur Peer-to-Peer-Synchronisation. Die Einschränkung liegt bei Aufgabenklassen, die eine strikte zentralisierte Kontrolle erfordern (z. B. Finanzsysteme).
Die Ergebnisse lassen sich nicht auf Leistungsmetriken reduzieren – in den Ausgangsdaten sind keine enthalten. Die Veränderung findet auf der Ebene der Kontrollverteilung und der Ausfallsicherheit gegenüber externen Einflüssen statt. Systeme werden unempfindlicher gegenüber Blockaden und politischen Risiken, bezahlen dies jedoch mit Komplexität und dem Verzicht auf Optimierungen eines spezifischen Anbieters.
Das gemeinsame Muster bei allen drei Ansätzen ist die Abschwächung der Abhängigkeit durch Standardisierung und Dezentralisierung. Dies ist keine kostenlose Verbesserung, sondern ein bewusster Kompromiss: mehr Engineering-Aufwand im Austausch für Vorhersagbarkeit unter Bedingungen, bei denen ein Ausfall keine Degradation, sondern den Verlust des Zugriffs bedeutet.