У Брюса Уэйна есть деньги, влияние и ресурсы.
У Бэтмена — скорость, гибкость и гаджеты на все случаи жизни.
Но по отдельности один без другого не может: без Брюса неоткуда взять технологии, а без Бэтмена они не имеют смысла. Только вместе они закрывают проблемы, с которыми поодиночке не справились бы.
Гибридная инфраструктура работает (примерно) так же: свой контур дает контроль и стабильность, а облако — быстрые мощности и гибкость.
Вот только 9 из 10 клиентов вообще не задумываются, что такое гибридное облако на самом деле и какой профит можно от него получить. Чаще всего в качестве центра притяжения работает свой ЦОД и плюс пара сервисов (вроде виртуалок и S3 для бэкапов) у провайдера. Вот и весь гибрид.
Меня зовут Владимир, я тружусь над гибридными облачными сервисами в Cloud.ru. И раз уж это моя работа, то я хочу разобрать гибрид на пальцах, чтобы вы могли требовать от вашего облачного провайдера большего. Возможно, к концу текста может оказаться, что ваш текущий «гибрид» гибридом вовсе не является. Зато возникнут новые идеи и запросы к инфраструктуре.
Облачный ликбез
Когда речь заходит о мощностях, многие представляют простую развилку: либо серверы стоят в вашем ЦОД (либо вы покупаете колокейшен), либо вы арендуете мощности у провайдера, выбирая нужные сервисы, и доверяете ему свои данные. На практике все устроено немного сложнее и интереснее.
Сегодня у бизнеса есть четыре варианта.
Первый — классический on‑premise: все свое и знакомо до последней материнской платы. Благословенны были те, кому не нужно было срочно замещать «уютную Варю». Однако вопрос, куда двигаться дальше, актуален и для самых консервативных инфраструктурщиков.
Второй — частное облако: та же идея контроля, но уже в облачной модели. По сути, вы строите свою облачную платформу в собственном ЦОД. Тут тоже развилка: либо у вас есть своя команда, которая говорит, что умеет готовить OpenStack и кубер, либо вы идете к кому-то из импортозаместителей. Там вам также говорят: «Мы умеем готовить OpenStack и кубер/oVirt и Proxmox, продукт реестровый, одна из отечественных 92 платформ импортозамещения виртуализации».
В вашем частном облаке вы разворачиваете корпоративные приложения, базу данных. А если у вас сертифицированный ФСТЭК дистрибутив платформы, то вы можете аттестовать контур для запуска нагрузок ЗОКИИ.
Еще один популярный сценарий — это облако для внутренних команд разработки. Разработчики получают безопасную среду с полным контролем над данными. Самая популярная история, это взять ванильные OpenStack и Ceph и развернуть их. По статистике OpenInfra Foundation, —некоммерческой организации, которая приютила под своим крылом OpenStack и его составные части-проекты — самый популярный размер инсталляции — от 1 000 до 9 999 ядер. Это примерно от 15 до 150 физических серверов.
Ванильный OpenStack — неплохой вариант. Но и у Ceph есть свои болезни, которые, будучи не вылеченными, приводят к развалу инфраструктуры.
Третий — публичное облако, где вы быстро получаете ресурсы без закупки железа и длинных циклов согласования. Удобно для новых сервисов, экспериментов, пиков нагрузки и всего того, что не хочется сначала согласовывать полгода. Несмотря на то, что я занимаюсь гибридным и частным облаками, я все равно мотивирую заказчиков сначала попробовать публичное облако и присмотреться, например, к прототипам «цифровых кайзенов», которые можно быстро реализовать в публичном облаке.
И четвертый — гибрид. При таком варианте часть систем живет у вас, часть — в облаке. Между ними не случайная перемычка, а единый контур управления и заранее проработанные и согласованные подходы, например: какие нагрузки живут только в приватном контуре, какие можно запускать в паблике, какие можно масштабировать за счет облачных ресурсов, когда своего ЦОД не хватает.
Отдельная история — мультиоблако. В обычном понимании, это использование сервисов от нескольких облачных провайдеров одновременно. Предполагается, что у заказчика локально или в одном из облаков стоит универсальный облачный оркестратор, подключенный к публичным облакам и собственным платформам виртуализации. Зайдя в него, можно выбрать себе нужное количество ресурсов в подходящей среде.
Когда спрашиваешь заказчиков о гибриде, то они в один голос говорят, что идея им нравится. Но когда дело доходит до реальной покупки, оказывается, что интерес был больше гипотетическим. И на пути к внедрению стоит много стопперов: от безопасности до бюджетов.
Но значит ли это, что кейсов, где гибрид действительно нужен, мало? Нет.
Наша команда не так давно делала исследование по гибридным облакам, из которого очевидно главное: сама жизнь подталкивает бизнес к смешанным моделям. Другой вопрос, что понимания, как эти модели должны выглядеть, у многих до сих пор не появилось.
Но это на Западе. А как выглядит российский рынок гибридных сервисов? Сейчас расскажу.
Особый русский путь
Российское гибридное облако развивалось по маршруту, который заметно отличается и от западного, и от азиатского опыта.
Как было на Западе: сначала массовый уход в публичные облака по модели cloud‑first, потом осознание ограничений, появление гибридных решений от AWS, Azure и GCP и переход к осознанному hybrid‑first.
Как было в Азии: сначала западные провайдеры, затем национальные гиперскейлеры, а потом, под давлением регуляторики, гибрид.
В России в 2006–2016 годах компании активно пользовались AWS, Azure и Google Cloud для разработки и тестирования, но все равно были вынуждены сохранять собственную инфраструктуру для критичных данных.
Первым серьезным драйвером для гибридизации стали требования по локализации персональных данных (в том числе 242‑ФЗ): полностью «уехать в облако» было нельзя, поэтому приходилось комбинировать собственные ЦОД и внешние сервисы.
В период 2016–2021 годов иностранные облака оставались эталоном по технологиям, а отечественные платформы чаще использовали как способ соблюсти регуляторные требования и снизить CAPEX.
Именно тогда вошли в игру крупные российские провайдеры, которые сейчас определяют рынок: Cloud.ru, VK Cloud и Yandex Cloud. Бизнес все еще смотрел на них осторожно и основные нагрузки держал в on‑premise и частных контурах, а в публичные облака отдавал менее чувствительные задачи.
А дальше — 2022 год, санкции и уход западных провайдеров, которые вынудили компании экстренно мигрировать в российские облака или восстанавливать локальную инфраструктуру. Одновременно государство усилило поддержку национальных провайдеров, и рынок за несколько лет добился того, на что в других странах уходило десятилетие.
Результатом стала форсированная гибридизация: у компаний остались крупные on‑premise и частные сегменты, и к ним в срочном порядке подстраивались российские публичные облака. Архитектура вышла фрагментированной, без единой панели управления и стека, но именно так гибрид (фактический, а не терминологический) и стал нормой.
Что сейчас? Объем российского облачного рынка достиг 225 млрд рублей с двузначными темпами роста и прогнозом удвоения к 2029 году.
Мы в Cloud.ru запустили Evolution Stack — управляемую платформу для частного и публичного облака, с единой консолью, общей оркестрацией и единым технологическим стеком.
С самого начала мы проектировали ее как гибридное решение: построили публичное облако, затем добавили приватную часть и единые инструменты управления, чтобы компании могли работать с обоими контурами как с единой средой.
Немного внутрянки. В разговорах с потенциальными заказчиками почти никогда не звучит прямой запрос на гибридное облако. Чаще приходят с задачей на импортозамещение виртуализации или систем хранения данных, построение объектного S3-совместимого хранилища или модернизацию собственного ЦОД. По сути, это уже гибридная реальность, но бизнес формулирует запрос на языке инфраструктуры, а не архитектуры.
Вы справедливо спросите: на чем тогда основано решение развивать гибрид, если не на массовом спросе? Отвечу: на аналитике. Мы смотрим на мировой опыт и свои исследования гибридной инфраструктуры и видим, что гибридная модель становится новым стандартом.
В эту же сторону работает и наше партнерство с Гистех («ЕЦП»), которое мы заключили буквально на этой неделе. Суть: Гистех теперь дает аттестованную инфраструктуру для госсектора и разработчиков ГИС, а мы — облачные сервисы и единую платформу управления. На выходе клиент получает гибрид: прод с чувствительными данными крутится в частном контуре, а разработка и тесты — в отдельном регионе нашего публичного облака. При этом управление всеми слоями происходит через единую кодовую базу.
В итоге российский путь гибридизации оказался не плавной эволюцией, а быстрой реакцией на резкие негативные изменения. Получилось так, что гибрид стал ответом одновременно и на регуляторку, и на геополитику, и на потребность бизнеса сохранить привычный контроль, не отказываясь от облачных плюсов.
Что у гибрида под капотом
Здесь обычно начинается путаница. Поэтому объясню, как должен выглядеть эталонный супергерой — гибридный продукт, к которому мы в Cloud.ru и стремимся.
Предположим: есть ERP на земле и резервные копии где‑то снаружи в публичном облаке? Гибрид. Есть локальная база и пара тестовых стендов в облаке? Тоже гибрид. Есть старый ЦОД, который не хочется трогать, и новый сервис, который сразу запустили в облаке? Тоже гибрид.
А вот и нет. Гибрид упирается не в то, что часть ресурсов находится в разных местах, а в то, связаны ли они в одну рабочую систему.
У рабочего гибрида есть четыре опорных элемента.
Общий фундамент
Публичное облако и частное облако должны использовать единую кодовую базу: те же сервисы виртуализации, тот же Kubernetes. За счет этого, приложения можно переносить между контурами без рассинхрона версий и без неожиданностей в поведении.
Управление как одной системой
Для администратора гибрид не выглядит как два разных мира. Ресурсы в ЦОД клиента и в публичном облаке видны из одной консоли, с едиными ролями и политиками. Под это же управление можно подтянуть уже существующую виртуализацию, например наследованный кластер VMware, чтобы не жить в нескольких панелях одновременно.
Сеть
Частный и публичный контуры связаны единой управляемой сетью, а не набором случайных VPN‑туннелей. Этого достаточно, чтобы фронтенды в облаке спокойно ходили к базам и очередям в частном сегменте, а аналитика и ИИ-сервисы читали данные из обеих сред без ручной настройки маршрутов и фаервол‑правил.
Одинаковая оркестрация
Для разработчиков и эксплуатации гибрид выглядит как одна платформа. Приложения описываются и раскатываются одинаково, независимо от того, крутятся они в частном или публичном кластере: те же пайплайны, тот же мониторинг. Если в частном облаке не хватает ресурсов, платформа может докинуть мощности из публичного контура и перенести часть контейнеров туда.
И затем на базе предыдущих элементов собираются прикладные истории: частный контур держит критичные системы, публичный — резерв и быстрые среды для разработки и тестирования.
Пиковые нагрузки выносятся в облако, чтобы не покупать железо на несколько недель в году. Тяжелые ИИ‑задачи и GPU‑вычисления запускаются там, где это проще и дешевле, а инференс и работа с чувствительными данными остаются в своем контуре.
Вот как работает гибридная архитектура в общих чертах.
Если хотите узнать, что действительно работает в КИИ и как именно российские компании интегрируют ИИ в закрытом контуре, смотрите выступление нашей команды на ЦИПР.