Dependence on a single cloud provider has long been considered an acceptable trade-off. Now, it is increasingly viewed as a systemic risk with a high cost of failure.
The problem manifests not at the level of latency or throughput, but at the level of control. The European cloud market is highly concentrated: about 70% is held by three American providers. Moreover, even hosting data in regional data centers does not eliminate legal dependency. Precedents show that access to services can be restricted by external factors—sanctions or physical incidents. The probability of such events remains low, but is no longer zero. In highly dependent systems, this means a sudden and complete failure, not just degradation. This changes the risk class: from operational to strategic.
The proposed response is not isolation, but mitigating dependency through architectural constraints. The first approach is multi-cloud via standardization. The key idea is not abstract portability, but the ability to switch providers with minimal friction. This is achieved through de facto standards: S3 API for object storage, Kubernetes for orchestration, Kafka protocol for streaming, Postgres wire protocol for databases. The trade-off is obvious: increased operational complexity, higher costs, and abandoning vendor-specific features. It is a move toward the “lowest common denominator.” But the alternative—strict vendor lock-in—offers a worse risk profile.
The second approach involves protocols with a “credible exit,” using the AT Protocol as an example. The architecture is designed so that the user can switch providers without losing data and identity. Data is stored in personal repositories hosted on a personal data server (PDS). The aggregation layer (relay) forms an event stream, and the AppView builds indexes. Components can be operated by different providers. Even the centralized element (directory) is cryptographically secured and allows for forks. This shifts control: the platform ceases to be a choke point. The cost is a more complex consensus model and the need to support a protocol rather than a closed system.
The third approach is local-first architecture. Here, the source of truth is moved to the client side. The local copy of the data becomes the primary one, while the cloud acts for synchronization and backup. The technological foundation is CRDTs (conflict-free replicated data types), which allow changes to be resolved without a central coordinator. Practical implementation, such as Automerge, shows that this approach works for collaborative editing. This reduces dependence on the center and simplifies provider switching, all the way down to peer-to-peer synchronization. The limitation applies to classes of tasks that require strict centralized control (e.g., financial systems).
The results cannot be reduced to performance metrics—there are none in the source data. The shift occurs at the level of control distribution and fault tolerance against external impacts. Systems become less sensitive to blockages and political risks but pay for this with complexity and the forfeiture of specific provider optimizations.
The common pattern in all three approaches is the weakening of dependency through standardization and decentralization. This is not a free upgrade, but a deliberate compromise: more engineering work in exchange for predictability in conditions where a failure is not a degradation, but a loss of access.