Выбор между облаком и собственным ЦОДом, это не про технологии, а про управление рисками и деньгами. Решение принимается не на уровне приложения, а на уровне бизнес-процесса, и ключевой вопрос — кто и как будет нести ответственность за сбой.
Отказ от бинарного мышления
Первая ошибка — рассматривать «облако» и «on-premise» как взаимоисключающие варианты. Это не выбор между чёрным и белым, а поиск оптимального баланса для разных частей вашей ИТ-системы. Современная архитектура, это гибрид. Вопрос не в том, что выбрать, а в том, как распределить.
On-premise (собственная инфраструктура), это полный контроль, но и полная ответственность: от покупки сервера до замены вышедшего из строя блока питания. Облако, это аренда вычислительных мощностей у провайдера, где вы платите за потреблённые ресурсы, а провайдер отвечает за физическую инфраструктуру.
Но есть и промежуточные модели: аренда стоек в дата-центре (colocation), где вы ставите своё железо, но пользуетесь чужой «обвязкой» (электричество, охлаждение, каналы связи), или управляемые услуги, где провайдер поддерживает не только инфраструктуру, но и операционные системы, СУБД.
Критерии для распределения: не только стоимость
Решение принимается на пересечении нескольких осей. Рассматривайте их не по отдельности, а в комплексе.
1. Регуляторные требования и данные
Это главный ограничитель. Если система обрабатывает персональные данные (152-ФЗ) или гостайну, выбор сужается. Для информации, составляющей гостайну, облако не подходит в принципе — только изолированные государственные или аттестованные сегменты. Для персональных данных возможны облака с аттестатом ФСТЭК, но с жёсткими условиями: локализация данных и СУБД в РФ, российское юрлицо провайдера, техническая возможность для проверок.
Вопрос: готовы ли вы предоставить провайдеру доступ для проведения плановых и внеплановых проверок ФСТЭК? Если данные критичны и проверки нежелательны, on-premise становится предпочтительнее.
2. Характер нагрузки
Стабильная, предсказуемая нагрузка (например, бухгалтерский учёт, внутренний документооборот) хорошо ложится на on-premise. Вы можете точно рассчитать необходимую мощность и использовать её годами.
Нагрузка с резкими, непредсказуемыми пиками (промо-акции, сезонные распродажи, обработка событий в реальном времени) — кандидат в облако. Его главное преимущество — эластичность: масштабирование за минуты, а не за недели закупок.
Спросите себя: насколько часто ваша система простаивает? Если серверы загружены на 10% большую часть времени, вы платите за неиспользуемое железо. В облаке вы могли бы платить только за эти 10%.
3. Архитектурная связность и задержки
Компоненты, которые интенсивно обмениваются данными между собой (микросервисы в одном кластере, приложение и его кэш, веб-сервер и база данных), должны находиться близко друг к другу. Помещение части из них в облако, а часть оставив on-premise, создаст латентность, которая убьёт производительность.
Решение: выносите в облако или оставляете on-premise целые связанные блоки, а не их фрагменты. Например, весь фронтенд и stateless-сервисы — в облако, а ядро с транзакционной БД — on-premise.
4. Тотальная стоимость владения (TCO)
Сравнивать нужно не цену сервера с месячной арендой виртуальной машины, а полные затраты за 3–5 лет.
| Статья затрат | On-premise | Облако |
|---|---|---|
| Капитальные расходы (CAPEX) | Высокие: закупка серверов, СХД, сетевого оборудования, лицензий ПО. | Низкие или отсутствуют. Оплата по факту потребления (OPEX). |
| Операционные расходы (OPEX) | Электричество, охлаждение, аренда площадей, зарплата инженеров, техобслуживание, страховка. | Включены в тариф провайдера. Ваши OPEX, это мониторинг и управление облачными ресурсами. |
| Затраты на масштабирование | Высокие и дискретные: нужно покупать новое оборудование «впрок». | Низкие и постепенные: платите только за дополнительные ресурсы, когда они нужны. |
| Затраты на простои | Вы платите за оборудование, даже если оно не используется. | Вы не платите за остановленные или удалённые ресурсы. |
Для on-premise часто забывают про «скрытые» расходы: стоимость квадратного метра под серверную, повышающий коэффициент на электроэнергию для коммерческих организаций, утилизацию старого оборудования.
Практические шаги для анализа
Переход от теории к плану действий.
Шаг 1: Инвентаризация и классификация
Составьте полный реестр информационных систем и сервисов. Для каждого определите:
- Категорию обрабатываемых данных (персональные, коммерческая тайна, общедоступные).
- Паттерн нагрузки (стабильный, пиковый, непредсказуемый).
- Критичность для бизнес-процессов (минуты простоя = конкретные убытки).
- Архитектурные зависимости (с какими другими системами обменивается данными).
Шаг 2: Моделирование затрат
Для систем-кандидатов в облако используйте калькуляторы провайдеров (например, от VK Cloud или Selectel). Не ограничивайтесь «текущим» состоянием — смоделируйте сценарии роста и пиков. Для on-premise посчитайте TCO, включая все статьи из таблицы выше.
Важный нюанс: стоимость выхода из облака (egress traffic). Перенос больших объёмов данных обратно на свою площадку может быть дорогим. Заложите этот риск в модель.
Шаг 3: Оценка рисков и SLA
Сравните гарантии провайдера (SLA на доступность, время восстановления) с тем, что вы можете обеспечить сами. Часто внутренний SLA формально хуже, но реальный контроль над инцидентами выше. Риск блокировки аккаунта у провайдера из-за нарушения правил использования, это риск, которого нет on-premise.
Типичные сценарии распределения
Рассмотрим конкретные примеры, характерные для российского ИТ-ландшафта.
Сценарий 1: Веб-проект с пиковой нагрузкой
Интернет-магазин, медиа-портал. Фронтенд, балансировщики нагрузки, кэш (Redis), CDN для статики — в облако. Это даёт устойчивость к хакерским атакам типа DDoS и скачкам трафика. Ядро с заказами, платёжный шлюз и основная БД с клиентскими данными — on-premise или в управляемом сегменте с аттестатом. Так вы сохраняете контроль над самыми ценными активами.
Сценарий 2: Корпоративная инфраструктура
1С, почта, файловые хранилища, системы видеоконференцсвязи. Здесь часто выбирают on-premise из-за требований к внутреннему аудиту, интеграции с Active Directory и необходимости работы в условиях нестабильного интернета в филиалах. Однако, тестовые и разработческие среды для этих систем можно смело выносить в облако, чтобы не загружать основную инфраструктуру.
Сценарий 3: Аналитика и Big Data
Обработка логов, машинное обучение, ETL-процессы. Эти задачи требуют огромных, но кратковременных вычислительных ресурсов. Строить под них отдельный кластер on-premise экономически невыгодно. Их логично запускать в облаке, используя модели spot-инстансов (прерываемые ВМ) для снижения стоимости. Исходные и результирующие данные можно хранить в облачном объектном хранилище.
Ошибки, которые делают все
- Перенос «как есть» (lift-and-shift). Без изменений в архитектуре вы получаете все недостатки on-premise в облаке, но с ежемесячным счётом. Например, перенос монолита с постоянной работой ВМ.
- Игнорирование компетенций. Облако требует других навыков: не администрирования ОС, а управления сервисами через API, инфраструктурой как код (Terraform), контейнерами. Без этой команды проект обречён.
- Забыть про связность. Вынос одного сервиса без учёта его общения с другими через внутреннюю сеть.
- Считать облако всегда дешевле. Для стабильных, предсказуемых нагрузок on-premise почти всегда выигрывает в TCO за 3–5 лет.
Что делать дальше
Не пытайтесь принять окончательное решение за один день. Начните с пилотного проекта: вынесите в облако одну некритичную, но показательную систему (например, сайт-визитку или dev-среду). Измерьте реальные затраты, сложности, скорость развёртывания. Полученный опыт станет основой для стратегии распределения всей инфраструктуры.
Помните, что «облако», это не место, а операционная модель. Решение, это не разовый выбор, а непрерывный процесс адаптации архитектуры под меняющиеся требования бизнеса и регуляторов.