Привет, Хабр! На связи Алексей Боровиков, архитектор Astra Cloud.
Когда меня спрашивают, чем мы занимаемся, я часто слышу в ответ: «Понятно, облако делаете». Потом, разговор имеет два сценария развития. Либо в сторону «А что такое облако?», либо — «А, еще одно облако». Как понимаете, дискуссия не из легких. Но в любой ситуации все сводится к тому, что облако облаку рознь. Потому что за последние несколько лет я наблюдал, как этим словом называют все, что угодно.
В нашем случае за этим термином стоит конкретная инженерная философия, которая ломает привычные сценарии «сначала сделаем для себя, а потом как-нибудь упакуем в коробку». Именно так рождались все крупные провайдеры, и именно так рождалась куча проблем, с которыми мы теперь разбираемся.
NIST еще 15 лет назад четко прописал 5 признаков настоящего облака. Мы пройдемся по этому чек-листу, вспомним, через какие грабли проходили гиганты индустрии, и объясним, почему частное облако невозможно сделать простой доработкой платформы виртуализации. А заодно расскажем, как концепция вендорского облака позволяет не выбирать между «как в паблике» и «у себя на сервере». Погнали!
Операция «Эластичность» и другие заблуждения
Кажется, про облака сегодня не говорит только ленивый. Все пилят, интегрируют. Причем, каждый вкладывает в слово «облако» свой, глубоко личный смысл.
Давайте вспомним матчасть. Определению облачных вычислений уже много лет, так-то. Национальный институт стандартов и технологий (NIST) четко описал 5 признаков, без которых это просто громкое название:
Самообслуживание (Self-Service): захотел ресурс — получил сам, без звонка админу и согласования на три дня.
Универсальный доступ по сети: зайти можно откуда угодно и с любого устройства (ноутбук, смартфон, планшет).
Объединение ресурсов (Resource Pooling): ресурсы поставщика собираются в пул и делятся между всеми. Ты не знаешь, на каком конкретно сервере лежит твоя виртуалка и тебя это не беспокоит.
Эластичность: ресурсы должны выделяться и освобождаться по требованию пользователя без взаимодействия с поставщиком, в некоторых случаях автоматически.
Измеряемое обслуживание: платишь только за то, что использовал (процессорное время, гигабайты, IOPS), потому что облачная платформа автоматически контролирует потребление ресурсов используя данные измерений абстрактных величин.
Короче, если вам говорят: «У нас есть облако», — пройдитесь по этому чек-листу. И если провал хотя бы по одному пункту — поздравляю, у вас просто хорошая система. Но не облако.
Типичный сценарий, как не надо строить частное облако
Представьте ситуацию. Есть платформа виртуализации, есть команда эксплуатации, все работает. И тут приходит мысль: «А давайте сделаем из этого частное облако? Напишем квотирование, прикрутим биллинг, дадим доступ пользователям — красота!».
Звучит логично, но на практике это путь в никуда. Почему? Потому что платформы виртуализации исторически заточены под администраторов. Они сами в ручном или полуавтоматическом режиме обрабатывали заявки на выделение и освобождение каких-либо ресурсов. Эти заявки, как правило, проходили процесс согласования в какой-то внешней системе, который мог занимать не один день, и конечный пользователь не принимал в этом участия, только получал по факту параметры подключения к уже созданной нагрузке.
А тут появляется пункт №1 (самообслуживание), который ломает всю модель. Пользователь сам лезет в систему, а она к этому не готова.
Рождаются вопросы, на которые нет ответов:
Как дать пользователю права, но не отдать ему весь кластер?
Как автоматически распределить нагрузку между узлами?
Кто будет отвечать за все процессы?
В итоге вместо простой интеграции мы получаем глубокую переработку продукта, сдвиг сроков и, самое печальное, что вполне себе может случиться, — отказ от проекта.
Историческая справка о пути облачных гигантов
Любопытно, но почти все крупные облачные провайдеры прошли один и тот же тернистый путь. Никто не просыпался утром с мыслью: «А давайте-ка сделаем публичное облако и будем продавать его всем желающим».
Все начиналось с внутренней боли:
огромный штат разработки,
сотни заявок на выделение серверов,
процесс согласования длится дольше, чем сама разработка фичи.
Читать все вышеперечисленное, как раздутая инфраструктура, много ручного труда и утрата контроля за эффективностью утилизации оборудования.
Решение лежало на поверхности. Нужно дать разработчикам инструменты, чтобы они сами себя обслуживали, а мы будем лишь контролировать лимиты.
Первая стадия: Делаем для себя
Строились дата-центры, закупалось железо, разрабатывался софт. Нанималась целая команда, которая занималась только этим.
Вторая стадия: Коммерция
Когда внутренняя платформа достигала зрелости, возникал резонный вопрос: «На это потрачены миллиарды, как их отбить?». Эврика! Можно сделать из внутреннего облака публичное.
И тут начиналось самое интересное. Проект по созданию Public Cloud имеет сроки и бюджет. Внутри компании ты можешь себе простить падение не продакшн сервиса на 10–15 минут (с натяжкой). На рынке у тебя 100% продакшн по умолчанию. На рынке за сбои бьют деньгами (и репутацией). Поэтому в ход шли костыли и интеграции с существующими ИТ-системами провайдера.
Кейс: Эвакуация упавшего гипервизора
Чтобы выполнить SLA, надо быстро перенести и запустить ВМ с упавшего сервера. Но как понять, сервер реально умер или просто сеть «моргнула»?
Помечаем гипервизор, как дефектный.
Изолируем его, чтобы он случайно не очнулся и не испортил нам жизнь двойным запуском ВМ.
Варианты решения: выключение гипервизора по питанию через BMC (IPMI) или отключение портов на коммутаторе.
Первый сценарий может подвести, так как реализация IPMI может отличаться у различных вендоров оборудования и нет 100% гарантии, что сервер отключится и не включится повторно. Второй вариант считается более надежным, особенно если для платформы используются коммутаторы одного вендора. Вычисляем, к каким коммутаторам подключен сервер и отключаем порты этого сервера на коммутаторе. Скорее всего, будет выбран второй вариант.
Работает? Работает. Но это возможно только потому, что сеть под полным контролем провайдера. На одну инсталляцию пойдет.
Платформа плотно срослась с инфраструктурой. Всех это устраивало... пока не пришли заказчики с частными облаками.
Эпоха частных облаков и компромиссов
Итак, платформа отточена. CI/CD, контроль кода, бесшовные обновления. Но приходят заказчики, которые говорят: «Ребята, данные в публичное облако не пустим, регуляторы не велят, ИБ не велит, да и вообще не доверяем мы этим вашим интернетам. Хотим такое же, но у себя, On-Premise. Чтобы все как в паблике, но с перламутровыми пуговицами».
И тут выясняется, что продукт, который 5 лет отлично работал внутри инфраструктуры провайдера, не хочет работать на «голом железе» у заказчика. Значит необходимо упаковать имеющийся продукт в коробку. Но не все так просто.
Для контекста: коробкой мы называем дистрибутив, который можно принести в инфраструктуру заказчика, в том числе закрытый контур, и самостоятельно установить его на любое количество подходящего оборудования под требования конкретного проекта.
Заказчики народ требовательный. Доступ к сетевой инфраструктуре могут не дать, контуры закрытые без доступа в интернет, пользователи живут в домене и т.д.
Начинается эпоха компромиссов:
Какие из решений можно безболезненно поместить в коробку?
Какие компоненты для своего функционирования не требуют доступа в интернет?
Какие сервисы необходимы заказчику в первую очередь, а какие могут быть доставлены позже, после необходимых доработок?
Как доставлять обновления платформы в закрытый контур?
Как получить аттестацию?
В итоге то, что красиво демонстрировалось на пресейле, и то, что получилось после инсталляции, — две большие разницы. Функции, которые в паблике появлялись за неделю, у заказчика внедряются годами. И он сидит и смотрит на ваше публичное облако, понимая, что у него дома «VIP-версия» дискотеки 90-х.
Вендорское облако как решение проблем
Проанализировав все эти грабли (и свои, и чужие), мы пришли к простой мысли: облако должно изначально создаваться как коробочный продукт. Не как внутренняя платформа, которую потом пытаются продать, а как отчуждаемое решение, из которого можно собрать и Public, и Private Cloud.
Что такое вендорское облако на практике?
Мы не стали изобретать велосипед и пошли от противного. Копируем подход классического вендорского ПО, но переносим его в облачный мир.
Коробка — всему голова. Мы сразу делаем продукт с релизным циклом, сборкой, репозиториями и миграциями. Как любое коробочное ПО.
Свои ключевые технологии. Вендор сам разрабатывает и поддерживает ядро платформы, не зависит от стороннего Open-Source.
Прозрачная интеграция. Партнеры могут встраивать свои решения в платформу, понимают свои возможности и ответственность
Гибкость модели. Заказчик сам выбирает, как ему удобно: On-Premise, Off-premise или Public.
Качество вместо количества. Лучше сделать 5 нормально работающих сервисов, чем 50 генераторов проблем сопровождения.
Плюсы и минусы
Для заказчика все супер, не побоюсь так сказать:
✅ Он получает ровно то, что видел в демо-стенде публичного облака.
✅ Есть обязательства вендора по сопровождению, поддержке и обновлению.
✅ Можно влиять на roadmap продукта.
Для вендора (то есть для нас) есть и обратная сторона:
❌ Развитие платформы идет медленнее. Нельзя просто взять и «зашить» в продукт решение, которое подходит только для конкретного случая в конкретном ДЦ. Все должно быть универсально.
Но это тот случай, когда работает принцип Oracle: «Лучше меньше, да лучше». Мы сознательно идем на этот минус, чтобы не плодить зоопарк версий и не краснеть перед клиентом, у которого «в паблике работает, а у вас — нет».
Вместо заключения
Рынок облаков взрослеет. Эпоха «на коленке слепим из виртуализации и продадим» уходит. На смену приходят инженерно выверенные, коробочные решения. Потому что настоящая зрелость — это когда твое частное облако ничем не отличается от публичного. Только вендорский подход позволяет эту магию сделать реальностью.
Но технологии технологиями, а я хочу спросить у вас, Хабр: с какими граблями при переходе в облако сталкивались вы? Были у вас проекты, где «облако» оказывалось просто маркетингом? Или может, вы уже пробовали строить частное облако на базе вендорских решений? При каких условиях вообще компаниям выгодно становиться облачным провайдером? Делитесь опытом в комментариях, обсудим)
___
P.S. Если тема заходит, в следующем посте могу рассказать про наш конкретный стек. Черкните в комменты, интересно ли вам такое погружение в архитектуру.
