Lift-and-shift: когда перенос в облако не даёт ожидаемого результата
Почему механический перенос инфраструктуры в облако без изменения архитектуры сохраняет старые проблемы и добавляет новые расходы.
Перенос инфраструктуры в облако сейчас стал стандартным пунктом в стратегиях многих компаний. Аргументы понятны: меньше капитальных затрат на оборудование, гибкость масштабирования, снятие с себя части операционных задач.
Но я наблюдаю устойчивый паттерн в проектах, которые начинались с этих ожиданий. Компания переносит серверы в облако - виртуальная машина за виртуальной машиной, почти без изменений в архитектуре. Через несколько месяцев обнаруживается, что счёт за облако значительно выше, чем ожидалось, а гибкости больше не стало. Аналитики в компании называют этот сценарий "lift-and-shift" и относятся к нему скептически. Я разделяю этот скептицизм.
Что такое lift-and-shift и почему он привлекателен
Смысл простой: берёшь то, что работает на собственных серверах, и переносишь в облако в максимально похожем виде. Минимум изменений в коде и архитектуре, максимальная скорость миграции.
Это привлекательно, потому что снижает риск. Если ничего не менять - ничего и не сломается. Команда знакома с системой, нет необходимости переобучаться.
Проблема в том, что этот подход переносит не только приложения, но и их неэффективности. Система, спроектированная под постоянно работающие физические серверы, в облаке часто работает как постоянно запущенные виртуальные машины - с такими же накладными расходами, но по облачным ценам.
Откуда берётся разочарование
Несколько типичных ситуаций:
Простой ресурсов. Виртуальная машина, арендованная в облаке круглосуточно, стоит иначе, чем собственный сервер с амортизацией за несколько лет. Если нагрузка неравномерная - ночью и в выходные система почти не работает - платить за постоянную доступность означает платить за пустоту.
Хранилище данных и трафик. В собственной инфраструктуре перенос данных между серверами бесплатный. В облаке за исходящий трафик берут деньги. Архитектура, которая предполагает активный обмен данными между компонентами, может генерировать неожиданно большой счёт.
Лицензии. Часть корпоративного ПО имеет лицензионные условия, которые не предполагают использование в облаке или требуют другого типа лицензии. Это выясняется не всегда заранее.
В чём реальный аргумент за облако
Облачные сервисы дают ценность не тогда, когда они заменяют физический сервер виртуальным. Они дают ценность тогда, когда архитектура использует то, за что вы платите: эластичное масштабирование, managed-сервисы, которые не нужно поддерживать самостоятельно, глобальное присутствие.
Это требует переосмысления того, как устроены приложения. Не обязательно полного переписывания - но хотя бы анализа того, где текущая архитектура противоречит облачным принципам.
Вопросы для оценки перед миграцией
Прежде чем начинать перенос, имеет смысл задать несколько вопросов:
- Для каких систем мы ожидаем экономию, и на чём основаны эти расчёты?
- Как распределяется нагрузка на системы в течение дня и недели - есть ли смысл в эластичности?
- Какие компоненты можно заменить managed-сервисами, отказавшись от собственной поддержки?
- Есть ли лицензионные ограничения у используемого ПО?
- Кто сделал расчёт стоимости в облаке - и как он сравнивается с текущими затратами?
Облако - хороший инструмент при правильном применении. Механический перенос без ответов на эти вопросы часто приводит к разочарованию и лишним расходам.