Современные системы проектируются вокруг облаков, но зависимость от одного провайдера начинает проявляться как системный риск. Вопрос не в вероятности сбоя, а в его последствиях и способности системы пережить потерю контроля.
Проблема проявляется не на уровне latency или throughput, а на уровне управления. Европейский рынок облаков концентрирован: около 70% приходится на три американских провайдера. При этом даже размещение данных в региональных дата-центрах не устраняет юридическую зависимость. Практические инциденты показывают два класса отказов: политико-правовые (потеря доступа к сервисам из-за санкций) и физические (повреждение дата-центров с длительной деградацией сервисов). Вероятность таких событий остаётся низкой, но не нулевой. В системах с высокой зависимостью это превращается в риск с непропорционально большим impact.
Предложенный подход — не изоляция, а снижение связности через стандартизацию и децентрализацию. В backend-системах это выражается в multi-cloud через де-факто стандарты: S3 API, Kubernetes, Kafka protocol, Postgres wire protocol. Идея проста: возможность переключения (switching) важнее, чем оптимизация под конкретного провайдера. Trade-off очевиден — рост операционной сложности, дополнительные издержки и отказ от провайдер-специфичных возможностей. Это компромисс в пользу управляемости. Для пользовательских платформ предлагается модель “credible exit”: протоколы, в которых пользователь может сменить провайдера без потери данных и идентичности. В collaborative-инструментах — сдвиг к local-first, где облако становится вспомогательным слоем синхронизации, а не источником истины.
Реализация этих идей различается по слоям системы. В случае AT Protocol (Bluesky) данные пользователя хранятся в персональном репозитории, аналогичном Git. Персональные data server (PDS) могут подниматься любым провайдером. Слой relay агрегирует события, а AppView строит индексы. Даже при наличии централизованного компонента (директория пользователей) вводятся криптографические гарантии целостности и возможность форка. В local-first архитектуре данные по умолчанию находятся на клиенте, а синхронизация реализуется через CRDT (conflict-free replicated data types), как в Automerge. Это позволяет работать офлайн, упрощает смену провайдера и допускает peer-to-peer обмен. Ограничение тоже чёткое: такие подходы не подходят для систем с единственным источником истины над физическими ресурсами (например, банковские балансы).
Результаты носят архитектурный, а не метриковый характер. Снижается зависимость от конкретного провайдера и появляется контролируемый сценарий выхода. Системы лучше переносят частичную потерю инфраструктуры и юридические ограничения. Цена — усложнение эксплуатации и отказ от “лучших” проприетарных функций. Количественные метрики в исходных данных не приводятся, но качественный эффект — перераспределение контроля от провайдера к пользователю и оператору системы.