Казалось бы, облака давно разобрали по косточкам. Уже даже финдирам понятно, что и как там устроено. Но стоит только кому-то запустить новую платформу или свернуть проект, как начинается: а почему не в паблике? А почему не в приватке? А оно нам вообще надо? И пошло-поехало. Хотя на деле-то выбор часто донельзя очевиден, если знать пару нюансов.

Публичное облако: быстрое, удобное, чужое

Начнем с варианта, который сейчас на слуху буквально у всех. Речь, конечно, про публичные облака.

Их идея проста до безобразия: провайдер – Yandex Cloud, VK Cloud, Selectel, Cloud.ru и т.п. – держит железо, а вы пользуетесь им, отчисляя за это, возвышенно выражаясь, “по делам своим”. У вас есть API, есть необходимый инструментарий и панель управления, где можно все настроить через браузер. Но вы не знаете, где крутится ваш инстанс и в каком хранилище сложены все диски.

Впрочем, так работают практически все публичные облака: зашел, зарегистрировался, ткнул мышкой и получил виртуалку. Или кластер. Или базу данных. Или что вам вообще нужно. На все про все уходит от силы минут 10. 

Для стартапов, для экспериментов, для тестов это прямо то, что доктор прописал. Хотя не все участники нашего FinOps-комьюнити в Telegram согласны с этим. 

Даже по деньгам все честно: платите ровно по счетчику. Нет, не в смысле, что вас ставят на счетчик, как в 90-х. Наоборот: сколько ядер прокрутили, сколько гигабайт хранили, сколько трафика использовали — столько и заплатили. Модель так и называется – pay-as-you-go. То есть никаких авансов, капзатрат и платы за простой. Нужно больше ресурсов — берем и увеличиваем лимиты. Меньше — сокращаем. Красота. Но есть нюанс.

Облако, как ребенок, требует ответственности. Большой ответственности. Одна забытая dev-среда может нехило увеличить итоговый счет за месяц. Даже если вы ей толком не пользовались. Просто объяснять это будет некому: платить все равно придется. 

С контролем, кстати, тоже все нелегко. Провайдер даст вам SLA, даст гарантии, но если ему захочется поменять условия или повысить цены — поменяет и повысит. А ты (или мы с вами на вы?) сиди и обтекай. Конечно, всегда есть вариант уйти к другому. Но так обычно рассуждают те, кто никогда никуда не уходил. 

Потому что есть еще такая штука, как vendor lock-in. Вроде начинаешь с простых виртуалок, а через год обнаруживаешь себя сидящим по уши в экосистеме одного провайдера: managed-базы, балансировщики, специфичные сервисы вроде serverless или ML API. Захочешь съехать — привет, месяцы работы и переписывание кода. Миграция от одного провайдера к другому может слопать 20-40% годового облачного бюджета. И это еще довольно оптимистичная оценка.

Хотя всего этого можно избежать. Просто строимся на открытых, а не фирменных стандартах провайдера, и всего делов:

• Kubernetes вместо проприетарных оркестраторов.

• PostgreSQL вместо фирменных баз провайдера.

• S3-совместимые хранилища вместо специфичных API.

Хотя на практике все это требует дисциплины. И жертв. Потому что managed-сервисы провайдера часто реально удобнее. Они уже настроены, обслуживаются, резервируются. А самостоятельно поднять и поддерживать ту же базу данных — это отдельная головная боль и хотя бы еще один инженер в штат. Так что выбор тут между удобством сейчас и свободой потом. Угадайте, что выбирают чаще? То-то.

Мультиоблако в этом смысле ситуацию почти не спасает. Вы, конечно, можете размазать инфраструктуру по нескольким провайдерам. Но готовьтесь к тому, что команда должна знать несколько экосистем, понадобится централизованная система управления и единые процессы координации. А трафик между облаками стоит денег. И зачастую немалых.

Зато масштабируется паблик, как говорили мальчишки у нас во дворе, почти до неба. Нужно 10 000 ядер на 3 часа для нагрузочного теста? Пожалуйста. Потом выключил — и платишь только за 3 часа. Для компаний с плавающей нагрузкой это огромный плюс. Без облака пришлось бы держать железо под максимум круглый год, даже если работать на полную оно будет только пару недель.

Частное облако: свое, контролируемое, дорогое

Теперь другая сторона. Если публичное облако — про скорость и удобство, то частное — про контроль и независимость. 

По сути, это изолированная облачная инфраструктура, которая целиком принадлежит одной организации. То есть речь идет даже не о размещении серверов, а о модели предоставления ресурсов как таковой.

Развернуть частное облако можно как угодно:

• В своем дата-центре, если он у вас уже есть и вы готовы содержать здание с серверами

• В коло, когда вы арендуете стойки в коммерческом ЦОД, ставите свое железо и разворачиваете облачную платформу

• У провайдера, когда провайдер разворачивает облачную платформу на своей инфраструктуре только под вас

Неизменным остается одно: все ресурсы ваши, а значит, и контроль тоже ваш.​

Поэтому все те, кому в публичное облако нельзя (банки, телеком, госсектор и крупный ретейл), часто выбирают именно частные облака. Сказываются требования ЦБ, ФСТЭК и ФЗ-152, которые обязывают работать с критичными данными только в условиях тотального контроля со стороны компании. 

Впрочем, за частным облаком далеко не всегда стоит только нужда. Нередко его выбирают по доброй воле. Благо причин тоже хватает:

Во-первых, это предсказуемость затрат. Да, на старте придется вложиться и будет дорого. Зато потом платишь по фиксу и в ус не тарахтишь. Если ЦОД свой, оплачиваешь только электричество, амортизацию и зарплаты. Если hosted private cloud — аренду мощностей. Нет такого, как в паблике, когда счет может вырасти втрое за месяц, если вдруг какой-то гений забыл выключить GPU-инстанс.

Во-вторых, частное облако = стабильная производительность. Поскольку мощности не делятся с другими компаниями, нет фактора неудобных соседей. Иными словами, вам почти всегда – за совсем редким исключением – гарантирована постоянная скорость работы.​

В-третьих, кастомизация под различные задачи. Нужна нестандартная сетевая архитектура? Интеграция с legacy через внутренние VLAN? Своя конфигурация виртуализации? В приватке все настраивается под себя как угодно. В паблике такой свободы нет.

Минусы? Есть и таковые.

Главный — медленное масштабирование. Если вдруг понадобятся дополнительные мощности, а у вас свой ЦОД или коло, придется заказывать серверы и ждать. Ждать, пока доставят, пока смонтируют, пока настроят. А это в лучшем случае месяцев 5-6. В hosted private cloud ситуация не сильно лучше. Ведь провайдеру мощности тоже не старик Хоттабыч наколдовал. 

Следующий момент — цена. Развернуть и содержать приватку будет куда дороже, чем зарегистрироваться в паблике. В частном облаке попросту невозможно перераспределить ресурсы между клиентами. Провайдер сразу резервирует оборудование конкретно под вас. Хорошо это? Хорошо. Но не бесплатно. 

Высокой отказоустойчивости тоже просто так не добьешься. Чтобы система не упала при сбое, нужно дублировать буквально все. И лучше не по одному разу. Если в паблике все это уже учтено (хотя 100-процентную гарантию вам все равно никто не даст), в приватке такой роскоши нет. Вернее, есть – если заплатите.

Ну и команда. Чтобы частное облако работало, нужны частные люди (а лучше – не просто люди, а прямо инженеры с корочкой и опытом), которые это хозяйство будут обслуживать. Нет, конечно, провайдер может взять все на себя, но тогда счета станут больше. А там еще инфраструктура мониторинга, процессы, документация, регламенты. В общем, надо быть готовым. Это как минимум.

Что выгоднее: публичное или частное облако

Выше мы уже касались вопроса выгод и даже упомянули, что делать свое облако – это дорого. На это на этапе первоначальных вложений. А в долгую получается совсем обратная ситуация.

Поэтому надо считать TCO (Total Cost of Ownership). Это полная стоимость владения инфраструктурой за весь срок ее эксплуатации. В нее входит все: и покупка железа, и электричество, и зарплаты админов, и амортизация. Считать TCO нужно, чтобы понять, что будет выгоднее на длинной дистанции конкретно для вас.

Допустим, у вас постоянно крутится 200 виртуальных ядер. В паблике (Yandex Cloud, среднерыночные цены) это будет стоить примерно 3-4 млн рублей в год. В hosted private cloud (провайдер разворачивает приватку на своих мощностях, но только под вас) — около 2,5-3 млн рублей в год плюс единоразовый платеж за развертывание (от 500 тыс. до 2 млн). То есть на второй год приватка будет дешевле, поскольку мы теперь платим только за обслуживание.

Но если нагрузка прыгает, то в приватке придется держать много ресурсов в течение года. А это значит, что большую часть времени изрядная доля ресурсов будет банально простаивать. Ведь это в паблике ты платишь только за то, что используешь, а в частных облаках все иначе. Так что здесь паблик может оказаться выгоднее.

Отдельная история — AI и ML. Даже если вы строите свою приватку, иногда может быть выгоднее брать GPU для них в паблике. Ну, смотрите сами:

NVIDIA A100 80GB стоит под 2 млн рублей (не знаю, когда вы читаете этот текст и как изменился курс валют, но суть все равно плюс-минус должна быть ясна). Амортизация на 3 года — грубо 50 тыс. рублей в месяц. Звучит вроде даже терпимо, но только если GPU загружена круглосуточно. А если она простаивает хотя бы половину времени (например, используется только днем, а ночью стоит)? Тогда эффективную стоимость использования увеличиваем в 2 раза. К тому же GPU еще и устаревают быстрее обычного железа. Это тоже надо учитывать.

В паблике модель другая. Аренда A100 в том же Yandex Cloud стоит около 200-300 рублей в час. Для двухнедельного обучения модели (работает круглосуточно) это выходит порядка 70-90 тыс. рублей. Закончил — выключил и не платишь. А понадобилось через полгода снова — арендуешь снова. Для коротких спринтов с переменной нагрузкой типа обучения моделей раз в квартал, экспериментов или A/B-тестов паблик почти всегда будет выгоднее. Это аксиома.

Что безопаснее: частное или публичное облако

Казалось бы, мы уже выяснили, что тем же банкам в публичное облако нельзя, значит, и с безопасностью там все не ок. Ну, это не совсем правда. Просто в паблике действует модель разделенной ответственности. Это значит, что провайдер отвечает за физическую безопасность дата-центра, защиту гипервизора и сетевую инфраструктуру, а вы — за настройку ВМ, управление доступами, обновление ОС внутри инстансов и т.д.

Звучит вроде не страшно. Но данные-то все равно хранятся на сторонних серверах. А для многих отраслей такой вариант в принципе невозможен. Даже если провайдер получил все возможные сертификаты и закрыл требования по комплаенсу, ситуацию это особо не поменяет. 

Еще одна засада — соседи. В паблике ресурсы физического сервера делят между несколькими клиентами через виртуализацию. Если кто-то рядом запустил высоконагруженную задачу, ваша виртуалка может просесть по производительности. Или если на соседа идет массированная DDoS-атака, может зацепить и вас. Не то что бы это случалось каждый день, но риск есть.

В приватке все проще и сложнее одновременно:

Проще — потому что контроль полный. Из-за того, что данные никогда не покидают ваш защищенный периметр, вы можете пройти любой аудит и показать регулятору, что ручки – вот они. Все чистенько и безопасненько.

Сложнее — потому что вся ответственность лежит на вас, и если вы не озаботились вопросами безопасности, нагоняй от регулятора – это всего лишь вопрос времени. Ну, и денег, конечно. Потому что штрафы там ого-го.

IaaS, PaaS, SaaS: что в меню

Облака бывают публичными и частными, это понятно. Но еще есть градация по уровню сервиса:

1. IaaS (Infrastructure as a Service) — самый низкий уровень. На этом уровне провайдер предоставляет вам только виртуалки, сеть и диски. А весь головняк, включая установку ОС, настройку, деплой и полный контроль, ложится на вас. 

2. PaaS (Platform as a Service) — уровень повыше. Тут провайдер дает платформу для разработки и запуска приложений. Вы только пишете код, деплоите, а все остальное (ОС, обновления, масштабирование) делает сам провайдер. Такой вариант удобнее для разработчиков, но предлагает существенно меньше контроля.

3. SaaS (Software as a Service) — это уже готовый продукт под ключ. По сути, это как телевизор: никаких тебе настроек, подключений, просто включил и смотришь.

В паблике обычно есть все три уровня. Бери что хочешь и радуйся. В приватке не так. Там чаще всего встречается именно IaaS, иногда попадается PaaS (если строите на OpenStack с дополнительными сервисами). Но вот SaaS в частных облаках почти не бывает. Да и какой в них там смысл? Как говорится, не для того роза цвела.

А вот vendor lock-in, про который мы говорили ранее, сильнее всего именно на среднем уровне. Почему не на высшем? Да потому, что на нем вы вообще ничего не делаете, только потребляете. Поэтому знайте, что если просто крутить виртуалки (IaaS), миграция будет в разы проще.

Гибрид: когда не хочется выбирать

Не хочется выбирать из нескольких зол меньшее? Ну, 75% компаний так и делают. По данным исследований, только 15% организаций выбирают модель «все в паблике» и лишь 10% – только в приватке.

Речь, конечно, о гибридной схеме. Это когда часть инфраструктуры крутится в паблике, а часть в приватке. Причем варианты распределения могут быть вообще любые. Можно держать базовую нагрузку в приватке, а пики обрабатывать в паблике. Или прод в приватке, а dev и test в паблике. Или критичные данные в приватке, остальное в паблике. Или прод в приватке, а резервную площадку для disaster recovery в паблике. Тут уж, как говорится, up to you.

По сути, гибрид дает лучшее из двух миров. Но одновременно усложняет жизнь. Нужны инструменты для связи между приваткой и пабликом. Нужна экспертиза в обеих моделях. Нужна централизованная система мониторинга. Короче, головной боли не убавляется. Просто она становится разнообразнее.

Как связать приватку и паблик

Но допустим, вы все же решились на гибрид. Часть тут, часть там. Как их связать?

• Самый простой способ – это VPN-туннели. Поднимаете site-to-site VPN между своим ЦОД и пабликом, и всего делов. Работать оно, конечно, будет, но пропускная способность в такой модели взаимодействия сильно ограничена, да и латентность может скакать туда-сюда. В общем, для не самых критичных задач сойдет, но не более того.

• Вариант получше – Direct Connect или Express Route. Это выделенный канал напрямую к провайдеру. Поэтому скорость будет выше, а латентность стабильнее, но стоит такое удовольствие дороже. Плюс – провайдеры обожают драть три шкуры за трафик. 

• Для тех, кто хочет управлять всем централизованно и по-взрослому, есть SD-WAN. Он строится поверх существующих каналов (VPN, direct connect), добавляет интеллектуальную маршрутизацию, балансировку, QoS. В настройке такой вариант сложнее, но для крупных компаний с десятком площадок это практически безальтернативный стандарт.

Вроде бы хорошо и удобно: выбираешь то, что подходит, и пользуешься. Но главная засада гибрида – даже не в технологиях, а в том, что вам предстоит все это дело как-то отслеживать. То есть у вас должен быть единый мониторинг (он, конечно, нужен в любой инфраструктуре, но в гибриде без него быстро наступит хаос). Prometheus + Grafana помогают, но настроить их на оба облака — задача со своими нюансами, хоть и не ужас-ужас. Логирование тоже должно быть централизованным, чтобы логи сервисов, инфраструктуры и сетевого слоя стекались в один ELK-стек (или аналог). Поэтому готовьтесь к инцидентам. То VPN-туннель упал, то еще что. И ведь так сразу даже не поймешь, кто виноват: ваш ЦОД или провайдер облака. 

Сравнительная таблица: частное облако vs. публичное

Мы разобрали кучу деталей, теперь давайте соберем все в одном месте. Чтобы не путаться в нюансах и быстро вспомнить ключевые различия, вот сводная таблица:

Как видно из таблицы, идеальных решений не бывает. Паблик дает скорость и гибкость, но вы теряете в контроле и рискуете привязаться к провайдеру. Приватка дает полный контроль и стабильность, но требует больших вложений и своей команды. Выбор зависит от приоритетов: что важнее именно для вашего бизнеса прямо сейчас.

Как выбрать: публичное или частное облако

Что выбрать? Ответьте на эти вопросы, и станет понятнее:

• Нагрузка стабильная круглый год или скачет? Если стабильная, приватка на длинной дистанции будет дешевле. Если скачет (сезонные пики, непредсказуемый рост), скорее всего паблик.

• Есть своя IT-команда? Если есть своя IT-команда, способная тянуть инфраструктуру, можно думать про приватку. Если команда маленькая или фактически отсутствует (вы не готовы ее организовать), рациональнее идти в паблик.

• Регуляторика разрешает держать данные у стороннего провайдера? Если да, можно паблик или гибрид. Если нет (банк, госсектор, телеком), скорее всего только приватка или hosted private.

• Есть капитал на закупку железа? Если да (а в зависимости от масштаба сумма может достигать десятков миллиардов рублей), можно развернуть приватку в своем ЦОД. Если нет, паблик или hosted private (арендованное у провайдера).

• Критична скорость запуска? Если да (стартап, MVP, срочный эксперимент), только паблик. Если нет (долгосрочный проект, можно подождать месяцы), можно и приватку.

• Планируете мигрировать между провайдерами? Если да, строимся на открытых стандартах: Kubernetes вместо проприетарных оркестраторов, PostgreSQL вместо фирменных баз, S3-совместимые хранилища. Если нет, можно спокойно юзать удобные managed-сервисы провайдера.

Если на разные вопросы ответы разные, скорее всего ваш вариант — гибрид.