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