Суверенитет облачной платформы через многоплоскостную архитектуру¶
7.0/10
Контекст¶
Обычно cloud sovereignty сводят к выбору региона, но авторы утверждают, что не менее важна архитектура платформы: регуляторные режимы вроде EU Data Act, NIS-2 и DORA требуют доказывать, где живут контроль, состояние, ключи и журналы, а не только где выполняются нагрузки.
Суть¶
Центральная идея — рассматривать суверенитет как свойство топологии плоскостей. OpenChoreo разделяет платформу на отдельные кластеры: плоскость управления хранит желаемое состояние и оркестрирует, плоскости данных выполняют нагрузки, плоскости наблюдаемости собирают телеметрию, плоскости рабочих процессов и взаимодействия обеспечивают CI/CD и портал. Решающая деталь — соединения: плоскости данных, наблюдаемости и рабочих процессов сами открывают исходящие mTLS-подключения к шлюзу плоскости управления, поэтому API-серверы кластеров с регулируемыми нагрузками не доступны из интернета, а плоскость данных продолжает работать при потере связи. Такая топология прямо отвечает на четыре вопроса аудитора: юрисдикция становится меткой на ресурсе DataPlane, логи остаются в регионе через региональную плоскость наблюдаемости, секреты лежат в выбранном хранилище, а смена провайдера превращается в изменение топологии, а не в переписывание. Паттерн сочетается с изоляцией арендаторов через виртуальные кластеры: инфраструктурный слой отвечает «кто изолирован», платформенный — «что может пересекать границы и можно ли это доказать», а стоимость масштабируется по числу юрисдикций, а не арендаторов. Авторы честно отмечают ограничения: топология не меняет юрисдикцию оператора, не обеспечивает контроль внутри границ и требует больше кластеров в эксплуатации.
Вывод¶
Вывод авторов: суверенитет — это не пункт в контракте, а распределение контроля, состояния, ключей и аудита, выраженное декларативно и версионируемое в Git. Такая топология превращает «суверенность» из обещания поставщика в свойство, которое платформенная команда может реально эксплуатировать и проверять при аудите.