Если вы читаете это, возможно, кто-то в вашей организации оправдывал сохранение той древней системы COBOL или тех серверов эпохи Pentium, которые пылятся в углу центра обработки данных. Вы слышали, как это называют «технической задолженностью», «необходимым злом» или — моё любимое — «мы перенесём это в следующем квартале» (мы оба знаем, что этого никогда не произойдёт).
Но что, если я скажу вам, что ваши устаревшие системы на самом деле могут приносить вам пользу? Не каким-то волшебным образом, а реально, измеримо, экономически обоснованно, о чём вам не расскажут проповедники модернизации?
Движение контркультуры, о котором никто не просил
Индустрия программного обеспечения стала одержима новыми блестящими вещами. Облако всегда кажется более зелёным по ту сторону, микросервисы — это ответ на всё, а если ваш технологический стек не был изобретён за последние три года, он фактически окаменел в янтаре. Но вот неудобная правда, которую никто не хочет признавать: устаревшие системы подобны тому надёжному старому автомобилю в вашем гараже — иногда лучше поддерживать его в рабочем состоянии, чем брать ипотеку на Tesla, которую вы пока не можете себе позволить.
Стабильность важнее новизны: недооценённое достоинство
Ваша устаревшая система работает уже много лет, иногда десятилетия. Она не интересна. В ней нет конвейеров машинного обучения или оркестрации Kubernetes. Она, вероятно, даже не может написать слово «serverless». Но знаете что она может делать? Она может работать. Последовательно. Предсказуемо. Не требуя степени PhD в DevOps, чтобы понять, почему она сломалась в 3 часа ночи.
Современные системы по своей природе хаотичны. Распределённые по нескольким облакам, управляемые десятками зависимостей, каждая из которых обновляется независимо по своему расписанию. Одно неудачное обновление зависимости — и внезапно ваша инфраструктура выглядит как башня Дженги после того, как кто-то чихнул. Устаревшие системы? Они застряли во времени. Они не обновляются сами. У них нет уязвимостей в цепочке поставок, скрывающихся в сторонних пакетах. Они скучные, блаженно стабильные.
Подумайте об этом: когда в последний раз вы слышали о том, что 30-летний мейнфрейм был скомпрометирован из-за уязвимости нулевого дня в пакете Node? Точно никогда. Не потому, что мейнфреймы неуязвимы для проблем с безопасностью — они не такие, — а потому, что они работают в контролируемой, понятной среде, которая была закалена десятилетиями реальных атак.
Скрытая экономика, о которой никто не говорит
Давайте поговорим о расходах. Да, обслуживание устаревших систем обходится дорого. Вам нужны специалисты, которые ещё помнят синтаксис COBOL, а запасные части стоят дороже нового автомобиля. Но вот где повествование разваливается:
Общая стоимость миграции баснословно высока
Ваш технический директор говорит, что миграция в облако сэкономит деньги. Вот что он, вероятно, забыл упомянуть: сама миграция стоит от 10 до 30% годового операционного бюджета системы. Вам нужны консультанты (дорого). Вам нужно переписать бизнес-логику, которая совершенствовалась на протяжении двух десятилетий (очень дорого). Вам нужно параллельно запускать обе системы во время перехода (дорого). Вам нужно справиться с неизбежными сбоями, которые происходят во время миграции (молитесь, чтобы этого не произошло, дорого, если всё-таки произойдёт).
Тем временем ваша устаревшая система продолжает работать. Она уже оплачена. Худший сценарий — сохранить её в текущем состоянии, что обойдётся дешевле, чем трансформировать её.
Бизнес-логика: непрезентабельный актив
Вот что делает профили Twitter с современной архитектурой очень неудобными: устаревшие системы часто содержат бизнес-логику, которую практически невозможно извлечь и воспроизвести.
Эта программа COBOL трёхлетней давности была написана не архитекторами, разрабатывающими элегантные решения. Она была написана прагматиками, решавшими реальные бизнес-проблемы, день за днём, решение за решением, патч за патчем. Каждое странное условие ветвления? Какое-то конкретное требование бухгалтера от 1987 года. Каждое странное вычисление? Нормативное требование, которое было включено в код. Каждая особенность? Представляет собой реальные знания о том, как работает ваш бизнес.
Когда вы пытаетесь «модернизировать» эту систему, переписывая её на Python и микросервисы, вы не просто переводите код. Вы пытаетесь извлечь институциональные знания, которые больше никто не понимает, потому что они никогда не были задокументированы. Первоначальный разработчик вышел на пенсию в 1998 году. Документ с требованиями был утерян, когда компания переезжала в 2003 году. Вы в основном играете в археологические раскопки с обзором кода.
Парадокс производительности
Все предполагают, что современные системы работают быстрее. Иногда это до смешного неверно.
Ваш тридцатилетний мейнфрейм для пакетной обработки? Он обрабатывает миллионы транзакций в час с эффективностью немецкой железнодорожной системы. Теперь вы хотите перенести его на облачную архитектуру с микросервисами, контейнеризацией, API-шлюзами и очередями сообщений. Внезапно вы вводите сетевую задержку, накладные расходы на сериализацию и фундаментальную сложность распределённых систем.
Иногда вам не нужен более быстрый автомобиль. Вам нужно перестать пытаться оптимизировать не то, что нужно.
# Вечные дебаты визуализированы
class LegacySystem:
def process(self, transactions):
# Запускается раз в сутки, завершается за 2 часа
# Никаких сюрпризов, никакой изменчивости
return self.batch_process(transactions)
class ModernSystem:
async def process(self, transactions):
# Обрабатывает в режиме реального времени с задержкой p99 в 50 мс
# Но требует автомасштабирования, мониторинга, оповещения,
# панелей управления, сценариев реагирования на инциденты
# Когда что-то ломается в 2 часа ночи, разбудите свою команду
return await self.distribute_and_conquer(transactions)
Реальный вопрос не «что быстрее?», а «что приносит вашей компании деньги?». Если ваша пакетная обработка завершается за два часа и никогда не сбоит, а современная система реального времени сократит это время до одного часа, требуя мониторинга 24/7 — вы только что купили себе проблему, а не решение.
Соответствие нормативным требованиям: скучная суперсила
Вот что заставит вашего специалиста по соответствию улыбнуться: устаревшие системы исключительно хорошо соответствуют требованиям.
Современные системы? Они постоянно обновляются, развёртываются новые версии, добавляются функции. Аудиторам это не нравится. Каждое изменение несёт риск. Каждое обновление — потенциальная уязвимость. Документация устаревает быстрее, чем вы успеваете её написать.
Устаревшие системы застыли во времени. Они были сертифицированы в 2008 году и до сих пор работают точно так же, как в 2008 году. Для строго регулируемых отраслей — банковская сфера, здравоохранение, производство — это на самом деле функция, а не ошибка. Вы можете провести аудит этих систем. Вы можете задокументировать их. Вы можете доказать, что они работают так, как вы утверждаете.
Построение вашей гибридной реальности: практические рамки
Если я не убедил вас поклоняться у алтаря устаревания, позвольте мне хотя бы предложить вам рамки для сосуществования с вашими устаревшими системами, а не для постоянного планирования их гибели.
Шаблон удушения: модернизация без катастрофы «ударить и заменить»
Не пытайтесь заменить всю свою устаревшую систему сразу. Так проекты умирают. Вместо этого используйте шаблон удушения: постепенно заменяйте части системы новыми компонентами, сохраняя при этом работу устаревшей системы.
Шаг 1: Определите свои границы
Посмотрите на свою устаревшую систему и найдите границы — внешние интерфейсы, через которые она взаимодействует с внешним миром.
Шаг 2: Постройте свой новый слой
Создайте новые сервисы, которые перехватывают вызовы устаревшей системы. Начните с наименее важных, наиболее заменяемых компонентов.
Шаг 3: Направлять разумно
Используйте уровень маршрутизации, чтобы определить, какие запросы направляются в новую систему, а какие — в устаревшую. Начните с 5% трафика для вашего нового сервиса.
Шаг 4: Мониторьте как ястреб
Не двигайтесь дальше, пока ваш новый компонент не докажет, что может надёжно обрабатывать производственный трафик.
Шаг 5: Повторите
Постепенно увеличивайте трафик для новых сервисов по мере того, как вы будете набираться уверенности. Ваша устаревшая система никогда не выходит из строя. Ваша команда остаётся спокойной. Все возвращаются домой вовремя.
# Реализация шаблона удушения
class RoutingLayer:
def __init__(self, legacy_system