Перенос в облако по принципу lift-and-shift: что скрыто в счёте
Почему перенос приложений в облако без переработки часто стоит дороже, чем казалось, и на что смотреть до начала миграции.
Облачная миграция стала стандартным пунктом ИТ-планов. AWS, Azure и Google Cloud активно предлагают инструменты переноса, консультанты готовы помочь, и на первый взгляд задача выглядит понятной: взять то, что работает на собственных серверах, и переместить в облако.
Самый быстрый путь - lift-and-shift: перенести виртуальные машины как есть, без изменений в архитектуре приложений. Это действительно быстро. Но в первые месяцы после миграции многие компании обнаруживают, что счёт оказался не тем, который ожидался.
Почему расчёт не сходится
Классический аргумент за облако - замена капитальных затрат (оборудование) на операционные (аренда мощностей). На бумаге это выгоднее: не нужно заморозить деньги в оборудовании, платить только за использование.
Проблема в том, что "платить только за использование" работает иначе, чем предполагается.
Приложения, написанные для работы на физическом железе, как правило, не оптимизированы под облачные паттерны потребления. Они держат выделенные ресурсы постоянно - как привыкли работать на выделенных серверах. В облаке это означает, что вы платите за ресурсы даже когда они не нужны.
Дополнительно: стоимость хранилища, сетевого трафика - особенно исходящего, - лицензий, которые не включены в облачный тариф, поддержки, резервного копирования. Всё это в собственной инфраструктуре было включено в общие расходы. В облаке каждая строка выставляется отдельно.
Три сценария, когда lift-and-shift разочаровывает
Системы с неравномерной нагрузкой, которые не масштабируются. Если приложение рассчитано на пиковую нагрузку и не умеет масштабироваться горизонтально - облако не даст экономии на idle-времени. Вы просто арендуете то же железо, только дороже.
Базы данных с большим объёмом данных и активной репликацией. Исходящий сетевой трафик в облаке платный. Если архитектура предполагает активный обмен данными между компонентами - счёт за трафик может быть сюрпризом.
Устаревшие лицензионные приложения. Ряд enterprise-лицензий при переносе в облако требует отдельного согласования с вендором или дополнительных лицензий. Это не вопрос облака - это вопрос лицензионных договоров.
Что стоит оценить до миграции
Я не против облака. Для многих задач это правильное решение. Но lift-and-shift требует честного расчёта.
Профиль нагрузки каждого компонента. Как меняется потребление в течение суток, недели, месяца? Есть ли периоды низкой нагрузки, когда ресурсы можно сокращать? Это определяет, насколько облако действительно выгоднее.
Структура трафика. Сколько данных передаётся между компонентами системы? Если большая часть обмена внутренняя - важно понять, как это будет выглядеть в облаке с точки зрения стоимости.
Лицензионные ограничения. Для каждого компонента - разрешает ли текущая лицензия работу в облачной среде? Какова стоимость перехода при необходимости?
Реальная стоимость альтернативы. Что стоит поддержание собственной инфраструктуры - включая персонал, замену оборудования, площадку? Это корректная база для сравнения.
Практический вывод
Перенос в облако - стратегически правильное направление для большинства компаний. Но "просто перенести" и "получить экономию" - не одно и то же. Lift-and-shift имеет смысл как временный шаг или как способ освободиться от управления железом - но не как способ сократить затраты без изменений в архитектуре.
Компании, которые получают реальную экономию от облака, как правило, на этапе миграции также оптимизируют архитектуру. Это дольше и дороже в начале - и значительно дешевле в эксплуатации.