Что такое Lift and Shift в миграции?

Lift and Shift: Миграция инфраструктуры в облако

Lift and Shift (также называют реингиниринг или 6R миграции) — это стратегия переноса приложений и данных из на-премной инфраструктуры (on-premises) в облако с минимальными изменениями архитектуры. Это одна из наиболее быстрых и дешёвых стратегий облачной миграции.

Что происходит при Lift and Shift?

Вы берёте приложение как есть (со всеми его особенностями и ограничениями) и буквально "поднимаете и перемещаете" его в облако:

1. Физический сервер → Виртуальная машина (VM) в облаке
2. Локальная БД → Database сервис в облаке
3. Файловые системы → Object Storage (S3, GCS, Azure Blob)
4. Конфигурация и сеть — переносятся с минимальными изменениями

Пример миграции Data Pipeline

До миграции (on-premises):

Crontab скрипт → Local PostgreSQL → File system (CSV)
     ↓
ETL скрипт на Python

После миграции (AWS):

CloudWatch Events/Lambda → RDS PostgreSQL → S3
     ↓
ECS контейнер с тем же Python кодом

Код практически не меняется, переносятся только инфраструктура и окружение.

Плюсы Lift and Shift

• Скорость — можно мигрировать за недели, а не месяцы
• Низкие затраты на миграцию — минимальное переписывание кода
• Быстрое получение преимуществ облака — масштабируемость, надёжность, резервные копии
• Минимальный риск — код работает как прежде, меняется только окружение
• Простота для знакомых технологий — если использовали Linux, PostgreSQL, Python — то же самое в облаке

Минусы Lift and Shift

1. Не извлекаются полные преимущества облака

   • Облако дорого работает с Legacy приложениями
   • Нет оптимизации под cloud-native архитектуру
   • Мониторинг и масштабирование работают плохо

2. Технический долг

   • На-премная архитектура может быть морально устаревшей
   • Сложнее добавлять новые функции

3. Дороговизна в долгосрочной перспективе

   • Облако дороже, чем на-премная инфраструктура для стабильных workloads
   • Legacy код сложнее масштабировать

Когда использовать Lift and Shift?

• Срочная миграция — есть deadline, нужна скорость
• Деcommissioning на-премной инфраструктуры — нужно быстро уйти из старого дата-центра
• Стабильные, проверенные системы — ETL/ELT pipelines, которые работают как часы
• Ограниченный бюджет на переразработку — нет денег на рефакторинг

Сравнение стратегий миграции (6R)

Реальный пример для Data Engineer

Мигрируем Airflow DAG с on-premises на AWS:

Было:

# Airflow на локальном сервере
from airflow.operators.bash import BashOperator

load_data_task = BashOperator(
    task_id="load_data",
    bash_command="/opt/scripts/load_data.sh",
    dag=dag
)

Стало (практически то же самое):

# Airflow на MWAA (Managed Workflows for Apache Airflow) в AWS
from airflow.providers.amazon.aws.operators.ecs import EcsRunTaskOperator

load_data_task = EcsRunTaskOperator(
    task_id="load_data",
    cluster="data-pipeline-cluster",
    task_definition="load_data_task",
    dag=dag
)

Код переехал в контейнер, но логика осталась той же.

Вывод

Lift and Shift — правильный выбор для быстрой, дешёвой миграции. Это НЕ оптимально с точки зрения облачной архитектуры, но это решение для реальных бизнес-сценариев, когда нужна скорость.