22 апреля 2000 г.
Облачные технологии в корпоративной среде давно перестали быть предметом обсуждения «стоит или нет». Сегодня это уже вопрос «как именно». Бизнес научился считать выгоды от переноса инфраструктуры в облако: снижение капитальных затрат, гибкость масштабирования, ускорение вывода новых сервисов. Однако вместе с этими преимуществами проявился и менее очевидный эффект — зависимость от провайдера.
Поначалу она казалась приемлемой платой за удобство. Но по мере роста цифровой зрелости компаний стало ясно, что привязка к одному поставщику влечет за собой технологические и экономические риски. Причем, сами провайдеры этого не скрывают.
Логичным решением антизависимости кажется мультиоблачная стратегия. Если не полагаться на одного провайдера, а распределить нагрузки между несколькими, можно снизить уязвимость и повысить устойчивость. Однако теория расходится с практикой.
Российская реальность: не мультиоблако, а гибрид
На уровне концепции мультиоблако выглядит универсальным решением:
- разные провайдеры,
- распределенные риски,
- свобода выбора сервисов.
Правда в реальных ИТ-ландшафтах эта модель почти никогда не реализуется в «чистом» виде. Причина в том, что отправной точкой для большинства организаций является вовсе не набор облаков, а уже существующая инфраструктура, которая сама по себе сложная, неоднородная и критичная для бизнеса. Полностью вынести ее в несколько публичных облаков зачастую невозможно или нецелесообразно.
Это связано с требованиями импортозамещения, повышенным вниманием к безопасности и необходимостью тотального контроля над данными, что особенно характерно для госсектора и крупных корпоративных структур.
Поэтому на практике мультиоблачность почти всегда «прорастает» через гибридную модель. К уже существующему on-premise варианту добавляются один или два облачных провайдера, каждый из которых решает свою задачу: масштабирование, резервирование, тестовые среды или запуск новых сервисов.
С одной стороны, такой подход дает бизнесу гибкость, не лишая его контроля. С другой, он создает новую проблему — фрагментацию инфраструктуры. Разные среды начинают жить по своим правилам, и без дополнительных усилий компания получает набор разрозненных ресурсов. Кто и как должен собрать этот инфраструктурный конструктор в работающую систему?
Ответ на этот вопрос неизбежно ведет к пересмотру сложившихся ролей. Еще несколько лет назад многие заказчики, особенно в финансовом секторе, работали по простой схеме: за все отвечал интегратор, клиент лишь пересылал ему запросы и согласовывал решения. Уход западных вендоров после 2022 года и одновременно резкий рост критичности ИТ (когда цифровые сервисы стали основой бизнеса) заставили компании иначе взглянуть на эту модель.
Сегодня заказчики вынуждены гораздо глубже вовлекаться в процессы: сами определять стратегию, напрямую работать с российскими вендорами, влиять на продуктовые дорожные карты. Роль интегратора при этом не исчезает, но смещается в сторону технической реализации. Он по-прежнему «крутит гайки», однако стратегическая повестка остается за клиентом. И чем сложнее и гетерогеннее становится инфраструктура, тем востребованнее прямое взаимодействие с теми, кто создает платформенные решения.
Международная практика
На самом деле, и в США, и в Европе, и в Китае «чистое» мультиоблако как самоцель встречается нечасто. В реальности там тоже доминирует гибридная архитектура, продиктованная контрактами, экономикой или регуляторикой.
Начнем с США. История Stack Overflow — это классический эволюционный гибрид. Компания долгие годы работала в собственном ЦОДе, но по окончании контракта с дата-центром приняла решение о миграции публичного продукта в Azure. При этом Stack Overflow for Teams (прим. — более узкий продукт B2B) был ранее перенесен в Azure с разделением кодовой базы, контейнеризацией и переводом на Kubernetes. Миграция заняла 3 года и потребовала нескольких попыток. В итоге сложилась архитектура, где часть сервисов и инструментов живут в Azure, а часть — например, отдельные аналитические или бэкофисные компоненты — остаются на других платформах.
Еще более показателен опыт GEICO. Страховой гигант почти 10 лет пытался мигрировать более 600 приложений в облако, следуя политике cloud-first. Но в 2024 году компания признала, что стратегия была ошибочной: расходы удвоились, надежность ухудшилась. Виной тому был так называемый фактор lift-and-shift, то есть перенос огромного массива унаследованных систем без рефакторинга. Поэтому GEICO решила все же вернуться к on‑premise на базе OpenStack и Kubernetes, одновременно сокращая 600 разрозненных систем до
В Китае же сформировалась своя модель гибрида, только государственного масштаба. Так называемые government cloud на уровне городов и провинций — например, в Вэйхае (провинция Шаньдун) или облачная платформа Гуанчжоу на базе Huawei — представляют собой централизованный IaaS/PaaS-слой для десятков ведомств. При этом они сочетаются с локальными дата-центрами и ведомственными системами. По сути, это гибрид, где унифицированный облачный контур дополняется локальной инфраструктурой, объединенной общей шиной и сервисами безопасности.
Европейский опыт интересен своим сервисным подходом к вопросу. Во Франции совместное предприятие Bleu (Capgemini + Orange) создано специально, чтобы вывести чувствительные государственные нагрузки (министерства, критическую инфраструктуру) в суверенное облако, сертифицированное по стандарту SecNumCloud 3.0.
Архитектурно мы получаем снова гибрид: у заказчика остаются свои ЦОДы и ведомственные системы, а рядом появляется суверенный облачный контур под контролем французских юридических лиц с ограничением доступа для не-EU персонала и интеграцией с экосистемой гиперскейлера.
Помимо этого крупный фреймворк-контракт Atos через государственный UGAP переводит более 300 французских госорганизаций на трехслойную модель:
- суверенное облако для персональных и чувствительных данных,
- публичные облака для менее критичных сервисов и фронтов,
- on‑premise ведомств для уникальных систем.
Немецкий пример еще конкретнее. Один из медицинских страховых фондов за 15 месяцев полностью перевел свою ИТ-инфраструктуру в суверенный облачный контур под юрисдикцией ЕС, где оказались данные пациентов и аналитика рисков. Менее критичные компоненты остались в стандартных публичных облаках. По сути, такая архитектура выглядит как строительство трехслойного гибрида: собственные ЦОДы плюс суверенное облако для критичных данных плюс глобальные гиперскейлеры для инноваций и масштабируемых сервисов.
Как видно из примеров, нигде нет стремления к «чистому» мультиоблаку ради самого мультиоблака. Это важный сигнал для российского рынка. Мультиоблако не является универсальным решением, которое автоматически снижает риски и расходы. Оно работает только при грамотном проектировании, учете реальной структуры legacy-систем и четком понимании, где экономически оправдано остаться на своих мощностях.
Важная роль вендоров в России
Роль российских вендоров сегодня становится критичной. Они фактически берут на себя функцию операторов мультиоблачной среды.
Работа начинается с аудита всей ИТ-инфраструктуры, включая локальные системы. Важно не просто зафиксировать текущее состояние, нужно понять взаимосвязи между сервисами, требования к производительности и ограничения по безопасности.
На основе этих данных проектируется архитектура:
- какие нагрузки куда переносятся,
- какие остаются внутри компании,
- как распределяются ресурсы между облаками.
После этого следует миграция. Как правило, поэтапная, с тестированием и минимизацией рисков для бизнеса. По-настоящему сложная часть начинается уже после переноса. Разнородная среда требует единого слоя управления, без которого мультиоблако превращается в набор изолированных решений. Именно этот слой обеспечивает централизованное администрирование, унификацию политик безопасности и контроль затрат. В идеале заказчик должен перестать видеть отдельные облака и начать работать экосистемно, то есть в единой среде, но это уже отдельный вопрос.
Дорога будет длинной
В конечном счете мультиоблако — это больше про контроль, чем про количество провайдеров. Еще это про возможность выбирать, перераспределять нагрузки и не зависеть критически от одного источника.
Такой уровень свободы не дается бесплатно. Он требует более сложной архитектуры, зрелых инструментов управления и компетентных партнеров. Поэтому переход к мультиоблачной модели редко бывает быстрым. Это постепенное движение, в котором важна управляемость.
Для российского бизнеса гибридное мультиоблако становится способом выстроить устойчивую ИТ-среду в условиях ограничений и неопределенности. И, судя по текущим тенденциям, этот путь только набирает обороты.
Источник: Константин Анисимов, заместитель генерального директора Astra Cloud (ООО «Астра Облако», входит в «Группу Астра»)
