Одно слияние компаний легко оставляет ИТ-службе две инфраструктуры, два набора пайплайнов и один неудобный вопрос: что из этого вообще нужно бизнесу. Для тех, кто отвечает за платформу, модернизация выглядит не как бодрый проект на 12 слайдов, а как разбор завалов после многолетнего корпоративного ремонта. Именно поэтому платформенные команды все реже верят в рецепт «просто переписать».
В материале Aarthi Mahesh и Steve Carter, как пишет The New Stack, проблема названа без дипломатии: слияния, поглощения и бесконечные внутренние инициативы плодят дублирующиеся платформы, процессы и команды. У компании внезапно оказываются два способа раскатывать сервисы, несколько каталогов IaC-шаблонов, пара систем секретов, разные политики доступа и отдельные контуры мониторинга, которые никто не рискует выключить. На квартальном отчете это можно продать как «гибкость». В эксплуатации это обычный операционный долг, который каждый релиз напоминает о себе чуть громче, и именно платформенные команды разбирают последствия первыми.
Контекст тут болезненно знакомый. Последние годы корпоративная модернизация почти везде продавалась одинаково: вынести legacy в облако, разрезать монолит, стандартизировать Kubernetes, а затем ускорить релизы и снизить зависимость от старого железа. Проблема в том, что бизнес меняется быстрее архитектурных программ. Пока одна команда строит «целевое состояние», другая покупает компанию, запускает новый продукт или переезжает на иной стек ради локальной задачи. В результате вместо одной аккуратной платформы получается набор временных компромиссов, которые живут дольше, чем их авторы в этой оргструктуре.
Отсюда и скепсис к лозунгу «просто переписать». Полный rewrite красиво смотрится в дорожной карте, потому что обещает стереть историю ошибок вместе с кодом. На практике он редко убирает главную проблему — накопленное разнообразие инфраструктуры и процессов. Даже если переписать сервис, никуда не исчезают IAM-правила, сетевые зависимости, требования к резервированию, особенности хранения данных и десятки неописанных краевых случаев, которые старая система научилась переживать за годы. Платформенные команды в такой ситуации получают не упрощение, а второй контур поддержки рядом с первым. То есть новую систему еще не любят, а старую уже нельзя бросить.
В этом месте разговор неожиданно перестает быть спором про «старое против нового» и становится разговором про эксплуатацию. Платформенным инженерам нужна не самая модная архитектура, а предсказуемая: единая модель обновлений, общие политики безопасности, понятный self-service для продуктовых команд и нормальный контроль над тем, что развернуто в дата-центре, в облаке и на периферии. Иными словами, платформенные команды хотят сократить число способов попасть в прод и число исключений, которые приходится помнить наизусть. Это скучная цель, пока не приходит аудит, инцидент или необходимость за неделю встроить в общий контур еще одну купленную команду.
Для разработчиков вывод достаточно приземленный: модернизацию стоит оценивать не числом переписанных сервисов и не красотой новой схемы в Confluence. Гораздо важнее, стало ли проще выпускать изменения, обновлять зависимости, чинить уязвимости и передавать сервис между командами без ритуала посвящения. Если новый стек требует отдельной группы хранителей, трех новых исключений в безопасности и ручного чек-листа на каждый релиз, это не ускорение, а дорого оформленная путаница. Для продактов и IT-директоров здесь тоже плохая новость: дублирующая инфраструктура ест не только облачный бюджет, но и скорость вывода функций на рынок.
Для бизнеса цена вопроса еще выше, чем кажется. Каждая параллельная платформа означает дублирование лицензий, больше точек отказа, более длинный онбординг и рынок найма, где вам одновременно нужны люди под старый, промежуточный и «стратегический» стек. HR в IT это знают особенно хорошо: найти инженера под один зрелый контур сложно, а под три несовместимых — уже почти спорт с элементами мазохизма. Неудивительно, что в центре внимания оказываются не грандиозные миграции, а инвентаризация, консолидация и деактивация лишнего. Героизма в этом мало, пользы — заметно больше.
Поэтому разговор о модернизации постепенно смещается с идеологии на метрики. Сколько у компании реальных путей в прод? Сколько времени занимает массовое обновление компонентов? Сколько команд обслуживают один и тот же класс инфраструктурных задач? Где дублируются шаблоны, политики и контрольные процедуры? Пока на эти вопросы нет ответа, любая «полная перепись» рискует стать просто еще одной платформой поверх существующих. И главный вопрос здесь уже не технический, а управленческий: кто в компании готов не строить следующий временный слой, а выключать лишний.