Legacy и миграции

5 мин чтения

Strangler Pattern: как заменить legacy-систему без большого взрыва

Полное переписывание выглядит чисто на схеме и рискованно в бизнесе. Strangler Pattern позволяет переносить систему по частям, сохраняя работающий продукт между этапами.

Когда старая система начинает мешать развитию, идея переписать её целиком кажется привлекательной. Новая архитектура, чистый код, современные технологии — и однажды мы просто переключимся.

Проблема в слове «однажды». Пока новая система строится, старая продолжает меняться, бизнес ждёт, а риск большого переключения растёт.

Strangler Pattern предлагает другую стратегию: не заменять всё сразу, а постепенно переносить функции из старой системы в новую.

Какую проблему мы решаем

Снаружи пользователи продолжают работать с привычным продуктом. Но отдельные запросы постепенно начинают обслуживаться новыми компонентами.

Сначала можно вынести один относительно независимый сценарий, затем второй. Старый код уменьшается по мере того, как его функции переходят в новую систему.

В результате миграция становится последовательностью небольших изменений вместо одного огромного события.

Что получает бизнес

Главная выгода — снижение ставки на один большой проект.

Компания начинает получать результат частями, а не ждёт несколько лет до полного переписывания. Каждый перенесённый сценарий можно отдельно проверить, измерить и при необходимости скорректировать направление.

Это уменьшает риск ситуации, когда бюджет уже потрачен, новая система ещё не готова, а старая всё равно должна продолжать развиваться.

Есть и возможность менять приоритеты. Если определённая часть legacy особенно дорого тормозит бизнес, её можно перенести раньше. То, что пока работает достаточно хорошо, оставить на потом.

То есть инвестиции идут туда, где старая система уже создаёт реальную цену.

Что получает команда

Команда может проверять новую архитектуру на реальных сценариях постепенно. Ошибка в одном этапе не обязательно ставит под угрозу всю миграцию.

Появляется возможность учиться по ходу проекта и уточнять границы новой системы, а не пытаться спроектировать всё идеально заранее.

Но некоторое время приходится поддерживать сразу два мира: старый и новый.

Что получает клиент

Клиент получает эволюцию вместо резкой смены всего продукта. Отдельные функции могут улучшаться постепенно, а большая часть привычных процессов остаётся стабильной.

Это снижает вероятность массового сбоя в день большой миграции и позволяет откатывать локальные изменения проще.

Чем мы за это платим

Цена постепенности — временная архитектурная сложность.

Нужно маршрутизировать запросы между старой и новой системами, синхронизировать данные, поддерживать совместимость и чётко понимать, где сейчас находится источник истины.

Есть и опасность, что «временное» состояние станет постоянным. Если у миграции нет понятного владельца и критериев завершения, компания может годами оплачивать две системы одновременно.

Когда Strangler Pattern не нужен

Если система небольшая, хорошо изолирована и её можно безопасно заменить за короткий срок, постепенная миграция может быть лишней.

Но чем критичнее система и чем больше вокруг неё интеграций, тем дороже становится ставка на одномоментный переход.

Что стоит спросить перед решением

В итоге

Strangler Pattern не делает миграцию бесплатной. Он меняет профиль риска.

Вместо одного большого обещания «перепишем всё» бизнес получает серию небольших инвестиций, каждая из которых должна приносить понятный результат.