Lift and shift — это перенос приложения в другое ИТ-окружение без заметной переработки его архитектуры и кода. Чаще всего речь идёт о миграции из локальной инфраструктуры в облако, когда приложение, данные и операционная система переносятся почти в исходном виде.
У этого подхода есть и второе название — ре-хостинг. Он помогает переехать быстрее, чем при глубокой переделке системы, но подходит не всем нагрузкам и не всегда даёт выгоду в долгой перспективе.
Содержание статьи
Как работает lift and shift
Lift and shift работает по простому принципу: существующее приложение берут в его текущем состоянии и перемещают на новую инфраструктуру. Логика работы сервиса для пользователей при этом обычно не меняется.
Обычно переносят не только само приложение, но и связанные с ним компоненты: базу данных, системные настройки, виртуальные машины, зависимости и операционную систему. Из-за этого миграция выглядит как перенос уже собранной конструкции, а не как её пересборка с нуля.
Чаще всего такой сценарий используют при переходе из собственного дата-центра в публичное облако или приватное облако. Иногда он становится промежуточным шагом: сначала компания переносит систему как есть, а уже потом дорабатывает её под облачную среду.
Когда подход уместен
Lift and shift чаще всего уместен, когда нужно быстро перенести нагрузку без серьёзной переделки приложения. Такой вариант рассматривают для систем, которые уже в какой-то степени готовы к облачной среде, или для тех случаев, когда перенос нужен как временная мера.
Раньше этот подход применяли шире. По мере развития облачных архитектур стало заметнее, что перенос «как есть» не позволяет в полной мере использовать облачные сервисы, автоматизацию и особенности тарифной модели.
По этой причине сегодня lift and shift обычно рассматривают в более узких сценариях. Например, для виртуализированных нагрузок, контейнеризированных приложений, сервисов на базе микросервисов или как первый шаг перед последующей переработкой монолитной системы уже в облаке.
Какие плюсы даёт lift and shift
Главное преимущество lift and shift — быстрый перенос с минимальными изменениями. Это снижает объём работ на старте и помогает раньше перевести часть ИТ-расходов из капитальных затрат в операционные.
У подхода есть и другие практические плюсы. Они зависят от самого приложения, условий лицензирования и того, насколько хорошо система вообще чувствует себя в облаке.
- Быстрая миграция. Перенос занимает меньше времени, чем переработка приложения под платформенные облачные сервисы.
- Меньше вмешательства в код. Если архитектуру не меняют, команде не нужно сразу переписывать ключевые модули.
- Меньше риска для пользовательского опыта. Интерфейсы и поведение приложения обычно остаются прежними.
- Доступ к более современной инфраструктуре. После переезда приложение может работать на более актуальном оборудовании без закупки собственных серверов.
- Проще масштабировать ресурсы. Облако позволяет добавлять вычисления, хранилище и сеть по мере необходимости.
- Поддержка гибридной модели. Часть нагрузок можно оставить локально, а часть вынести в облако.
- Снижение нагрузки на собственный дата-центр. Чем больше приложений вынесено наружу, тем меньше расходов на сопровождение локальной инфраструктуры.
- Доступ к облачным механизмам безопасности. После миграции могут стать доступны централизованное управление доступом, многофакторная аутентификация и единые процессы защиты.
Но эти преимущества не возникают автоматически. Если приложение уже работает медленно или нерационально использует ресурсы, перенос сам по себе это не исправит. Более того, в облаке такая система иногда обходится дороже.
Где lift and shift может не сработать
Lift and shift не гарантирует ни снижение затрат, ни рост производительности. Если приложение плохо приспособлено к облаку, перенос без изменений может закрепить старые проблемы на новой инфраструктуре.
Есть несколько типичных ограничений. Монолитные и тесно связанные системы часто слабо используют облачную эластичность. Старые приложения могут зависеть от конкретного оборудования, нестандартных сетевых настроек или узких мест в интеграциях.
Отдельный вопрос — лицензии. Для некоторых продуктов перенос в облачную среду связан с дополнительными платежами, ограничениями по размещению или прямыми запретами. В таких случаях проект нужно проверять до начала миграции, а не после.
Чем lift and shift отличается от других вариантов миграции
Lift and shift относится к миграции на уровне IaaS — инфраструктуры как услуги. Приложение переносят почти без изменений и размещают на облачной инфраструктуре, за которую платят по подписке или по фактическому потреблению.
Альтернативы обычно связаны либо с доработкой приложения под облако, либо с заменой самого решения. Разница здесь принципиальная: меняется не только место размещения, но и сама модель эксплуатации.
Миграция на PaaS
PaaS предполагает адаптацию приложения под платформенные сервисы облачного провайдера. Это может быть частичная оптимизация, смена платформы, переработка архитектуры или более глубокая модернизация.
При таком подходе приложение может лучше использовать автоматизацию, механизмы отказоустойчивости, средства безопасности и модель оплаты по потреблению. Но стартовые затраты времени и ресурсов обычно выше, чем у lift and shift.
Переход на SaaS
SaaS означает замену локального приложения на готовый облачный сервис с похожими функциями. В этом случае компания переносит не текущую систему, а сам рабочий процесс в другое программное решение.
Такой вариант иногда сочетает сравнительно простой переход с преимуществами облачной модели. Но приходится учитывать ограничения готового сервиса: доступные функции, формат управления данными, правила доступа и встроенные механизмы безопасности.
Lift and shift и VMware
Для сред на базе VMware lift and shift часто оказывается одним из самых прямых сценариев миграции. Если локальная и целевая облачная среда используют совместимую VMware-инфраструктуру, перенос проходит заметно проще.
Обычно для такого сценария важны три условия: общий гипервизор VMware ESXi, совместимые инструменты управления на базе VMware и vSphere API и команда, которая умеет сопровождать этот стек. Без этого перенос виртуальных машин «как есть» теряет часть своей простоты.
Ключевую роль здесь может играть VMware HCX — Hybrid Cloud Extension. Этот инструмент помогает расширить локальную сеть в сторону облачной VMware-среды, упростить построение гибридной инфраструктуры и переносить большое количество виртуальных машин без переработки приложений.
Дополнительно HCX используют для репликации и сценариев восстановления. Это делает VMware-нагрузки одним из наиболее понятных примеров, где lift and shift действительно может быть оправдан.
В каких случаях lift and shift выбирают чаще всего
Lift and shift обычно выбирают там, где нужен быстрый перенос, а переработка приложения пока невозможна или нецелесообразна. Это скорее практический компромисс, чем универсальная стратегия.
Есть несколько типичных ситуаций, в которых такой вариант встречается чаще.
- Нужно срочно сократить зависимость от локальной инфраструктуры. Если расходы на собственный дата-центр растут, приложение могут временно перенести в облако до более глубокой модернизации.
- Переносятся готовые коробочные продукты. Если приложение нельзя изменить на уровне архитектуры, перенос «как есть» остаётся одним из немногих реалистичных вариантов.
- Нужны резервное копирование и восстановление в облаке. Для части нагрузок облачная среда подходит как площадка для бэкапов и аварийного восстановления.
При этом ресурсоёмкие устаревшие системы требуют отдельной оценки. Если приложение потребляет много вычислений, хранения или сетевых ресурсов, оплата по потреблению может оказаться выше ожидаемой.
Как оценить lift and shift перед миграцией
Перед переносом нужно проверить, даст ли lift and shift реальную пользу именно для этой системы. Важны срок жизни приложения, технические зависимости, требования по соответствию нормам и возможные ограничения у провайдера.
Без такой оценки легко перенести в облако приложение, которое скоро будет выведено из эксплуатации, упереться в ограничения API или получить дополнительные расходы из-за неучтённых особенностей лицензирования.
- Оцените срок жизни приложения. Если систему планируют вывести из эксплуатации в ближайшем будущем, перенос может не окупиться.
- Проверьте ограничения по API и интеграциям. После миграции не должно появиться новых узких мест в текущих связях между сервисами.
- Узнайте, какие средства автоматизации миграции доступны. Инструменты провайдера могут заметно сократить объём ручной работы.
- Определите порядок переноса. Если приложений несколько, нужен понятный сценарий миграции и приоритеты для критичных систем.
- Проверьте требования по соответствию нормам. План миграции и инфраструктура провайдера должны закрывать требования, которые действуют во время и после переноса.
- Ограничьте объём проекта. Во время миграции легко начать параллельно внедрять новые облачные функции, из-за чего сроки и ресурсы уходят в сторону.
Когда лучше не ограничиваться lift and shift
Если цель — получить от облака максимум, одного lift and shift часто недостаточно. Перенос без переработки редко раскрывает преимущества облачно-нативной архитектуры.
Это особенно заметно у приложений, которым нужны автоматическое масштабирование, глубокая отказоустойчивость, тонкая оптимизация затрат и активное использование платформенных сервисов. В таких случаях полезнее рассматривать переработку под PaaS или замену на SaaS, а не только перенос инфраструктуры.
Есть и более простой ориентир. Если приложение уже сегодня страдает от архитектурных ограничений, то после переезда эти ограничения останутся. Изменится площадка, но не сама природа проблемы.
Коротко: что нужно помнить о lift and shift
Lift and shift — это быстрый перенос приложения в облако без существенной переделки. Подход удобен как стартовый шаг, но его ценность зависит от того, насколько приложение совместимо с облачной средой и какие цели ставятся после миграции.
Он подходит для ускоренного переезда, для части VMware-нагрузок, для коробочных решений и для некоторых сценариев резервирования. Если же задача связана с долгосрочной оптимизацией архитектуры, затрат и масштабирования, одного ре-хостинга обычно мало.
