Около 70% европейского облачного рынка контролируют AWS, Azure и Google Cloud, тогда как доля локальных провайдеров держится примерно на уровне 15%. На этом фоне технологический суверенитет перестаёт быть политическим лозунгом и становится вполне инженерной задачей: если критическая инфраструктура зависит от чужой юрисдикции, проблема однажды придёт не в презентацию, а в прод.
Именно об этом на QCon London говорил Мартин Клеппманн, профессор Кембриджского университета и автор Designing Data-Intensive Applications, как пишет InfoQ. Его тезис звучит жёстко, но без лишней драмы: цифровая инфраструктура теперь так же критична, как энергоснабжение или банковская система, а значит, зависимость от нескольких американских облаков уже нельзя считать просто удобной рыночной нормой.
Аргумент Клеппманна строится не на абстрактной «цифровой независимости», а на довольно приземлённых сценариях. Первый риск — санкции и политическое давление. В качестве примера он вспоминает историю с Международным уголовным судом в Гааге: после санкций США против главного прокурора Карима Хана тот лишился доступа к почте, размещённой у Microsoft. Associated Press цитировало ситуацию как отмену его адреса, а сама Microsoft отрицала, что «приостанавливала сервисы», но при этом подтверждала, что санкционированный чиновник был «отключён» от сервисов компании. Формулировка скользкая, но вывод Клеппманна вполне прозрачный: если государство давит на поставщика, поставщик может оказаться сильнее договора, SLA и красивых обещаний про нейтральную платформу.
Второй риск — иллюзия, что европейский дата-центр автоматически решает проблему. Клеппманн ссылается на позицию Microsoft: если власти США потребуют данные гражданина ЕС, размещённые в Европе, компания выполнит это требование вне зависимости от европейского права. Иными словами, география стойки и география штаб-квартиры — это две разные вещи, и в спорной ситуации важнее оказывается не адрес дата-центра, а юрисдикция владельца сервиса. Для российских, восточноевропейских и вообще любых неамериканских команд это звучит как неприятное, но полезное напоминание: compliance по региону размещения не равен реальному контролю над системой. Технологический суверенитет в такой логике — это не «всё хранить поближе», а не строить критичные процессы на зависимости, которую можно выключить административно.
Третий риск ещё проще и грубее: дата-центр можно не только юридически отключить, но и физически повредить. Клеппманн приводит пример атаки Ирана на три AWS-центра обработки данных в ОАЭ с помощью дронов; как минимум один объект, по его словам, получил серьёзные повреждения, а региональные сервисы оставались существенно нарушенными. Здесь важен не столько конкретный инцидент, сколько смена статуса самой инфраструктуры. Когда облако стало основой для бизнеса, логистики, финансов, коммуникаций и госуслуг, оно автоматически превратилось в военную и экономическую цель. Это уже не бэк-офис и не скучный IaaS-слой, а часть критической инфраструктуры с тем же профилем риска, что у электростанций, трубопроводов и транспортных узлов.
Отсюда Клеппманн переходит к тому, что обычно интересует аудиторию сильнее геополитики, — к архитектурным выводам. Первый — мультиоблачность как защита от single point of failure на уровне поставщика и юрисдикции. Не в декоративном варианте, когда у компании есть аккаунты в трёх облаках, но весь прод реально живёт в одном, а в практическом: переносимые окружения, отказ от сервисов, которые невозможно заменить без переписывания половины платформы, и регулярная проверка сценария миграции, а не только его наличие в Confluence. Второй — стандартизация API де-факто. Если команда строит систему вокруг проприетарных интерфейсов конкретного вендора, она покупает не только удобство, но и будущую стоимость выхода. Третий — local-first подход, при котором приложение остаётся полезным даже при проблемах с центральной инфраструктурой, а пользователь не теряет контроль над собственными данными из-за чужой аварии, санкций или смены правил доступа. Четвёртый — AT Protocol как попытка построить более переносимую и менее платформенно-запертую модель социальных и пользовательских сервисов.
Для разработчиков здесь, пожалуй, самая неприятная мысль в том, что удобные managed-сервисы слишком долго продавались как естественный финал эволюции инфраструктуры. Клеппманн фактически разворачивает картину: максимум аутсорсинга даёт максимум внешней зависимости, а значит, архитектурная элегантность без суверенности может оказаться дорогим самообманом. Для CTO и платформенных команд это переводится в довольно конкретный список вопросов. Что произойдёт, если основной облачный провайдер станет недоступен на неделю? Какие данные и процессы реально можно вынести из одного облака без квартала аварийной разработки? Какие бизнес-функции продолжают работать локально или в деградированном режиме? Где у компании настоящие открытые интерфейсы, а где просто надежда, что вендор и дальше будет вести себя прилично? Для HR и фаундеров вывод тоже не самый уютный: рынок постепенно будет ценить не только людей, умеющих быстро прикрутить очередной облачный сервис, но и тех, кто умеет проектировать системы с запасом на политические, юридические и инфраструктурные сбои.
В этом смысле разговор о технологическом суверенитете уже вышел за пределы европейской повестки. Клеппманн использует Европу как самый наглядный кейс зависимости от американских провайдеров, но сам принцип универсален: если ключевая часть продукта, данных или клиентского доступа находится под внешним контролем, то это не просто технический долг, а стратегическая уязвимость. Следующий этап конкуренции между платформами, похоже, будет идти не только по цене, скорости разработки и набору AI-функций, но и по способности доказать одно простое свойство: систему нельзя выключить одним письмом, одной санкцией или одной ракетой.