Moderne Systeme werden um Clouds herum entworfen, aber die Abhängigkeit von einem einzigen Anbieter erweist sich zunehmend als systemisches Risiko. Die Frage ist nicht die Wahrscheinlichkeit eines Ausfalls, sondern dessen Konsequenzen und die Fähigkeit des Systems, den Kontrollverlust zu überstehen.
Das Problem zeigt sich nicht auf der Ebene von Latency oder Throughput, 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 Datenspeicherung in regionalen Rechenzentren nicht die rechtliche Abhängigkeit. Praktische Vorfälle zeigen zwei Klassen von Ausfällen: politisch-rechtliche (Verlust des Zugangs zu Diensten durch Sanktionen) und physische (Beschädigung von Rechenzentren mit langanhaltender Service-Degradation). Die Wahrscheinlichkeit solcher Ereignisse bleibt gering, ist aber nicht null. In Systemen mit hoher Abhängigkeit wird dies zu einem Risiko mit unverhältnismäßig großem Impact.
Der vorgeschlagene Ansatz ist nicht Isolation, sondern die Verringerung der Kopplung (Coupling) durch Standardisierung und Dezentralisierung. In Backend-Systemen äußert sich dies in Multi-Cloud durch De-facto-Standards: S3 API, Kubernetes, Kafka-Protokoll, Postgres Wire Protocol. Die Idee ist einfach: Die Möglichkeit des Wechsels (Switching) ist wichtiger als die Optimierung für einen bestimmten Anbieter. Der Trade-off ist offensichtlich – Zunahme der operativen Komplexität, zusätzliche Kosten und der Verzicht auf anbieterspezifische Funktionen. Dies ist ein Kompromiss zugunsten der Verwaltbarkeit. Für Nutzerplattformen wird das Modell des „Credible Exit“ vorgeschlagen: Protokolle, bei denen der Nutzer den Anbieter wechseln kann, ohne Daten und Identität zu verlieren. Bei kollaborativen Tools erfolgt ein Paradigmenwechsel hin zu Local-First, wo die Cloud zu einer unterstützenden Synchronisationsschicht wird und nicht die Source of Truth ist.
Die Implementierung dieser Ideen unterscheidet sich je nach Systemschicht. Im Fall des AT-Protokolls (Bluesky) werden die Nutzerdaten in einem persönlichen Repository gespeichert, ähnlich wie bei Git. Personal Data Server (PDS) können von jedem beliebigen Anbieter bereitgestellt werden. Die Relay-Schicht aggregiert Ereignisse, und die AppView erstellt Indizes. Selbst bei Vorhandensein einer zentralisierten Komponente (Nutzerverzeichnis) werden kryptografische Integritätsgarantien und die Möglichkeit eines Forks eingeführt. In der Local-First-Architektur befinden sich die Daten standardmäßig auf dem Client, und die Synchronisation erfolgt über CRDTs (Conflict-free Replicated Data Types), wie in Automerge. Dies ermöglicht Offline-Arbeit, vereinfacht den Anbieterwechsel und erlaubt Peer-to-Peer-Austausch. Die Einschränkung ist ebenfalls klar: Solche Ansätze eignen sich nicht für Systeme mit einer einzigen Source of Truth über physische Ressourcen (z. B. Bankkontostände).
Die Ergebnisse sind architektonischer und nicht metrischer Natur. Die Abhängigkeit von einem bestimmten Anbieter sinkt, und es entsteht ein kontrolliertes Exit-Szenario. Die Systeme überstehen den teilweisen Verlust von Infrastruktur und rechtliche Einschränkungen besser. Der Preis dafür ist eine komplexere Betriebsführung und der Verzicht auf die „besten“ proprietären Funktionen. Quantitative Metriken werden in den Ausgangsdaten nicht genannt, aber der qualitative Effekt ist eine Umverteilung der Kontrolle vom Anbieter zum Nutzer und Systembetreiber.