Ересь, которую никто не хочет слышать

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

Прежде чем закрыть эту вкладку, решив, что я сошёл с ума, выслушайте меня. Технический мир любит ругать устаревшие системы с пылом подростка, высмеивающего модный выбор своих родителей. Но вот в чём дело: устаревшие системы стали таковыми не случайно. Они стали устаревшими, потому что работали. Они так хорошо справлялись со своей задачей, что компании не могли позволить себе их заменить. Это не ошибка; это особенность.

Почему ваша «устаревшая» система может быть умнее, чем вы думаете

Парадокс стабильности

Вот что не озвучивают на конференциях: скучные системы не выходят из строя. Гравийный мейнфрейм вашей бабушки, который работает уже тридцать лет? Он стабилен так, как архитектура модных микросервисов, использующая семнадцать различных фреймворков JavaScript, никогда не сможет быть.

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

Рассмотрим такой сценарий: вы используете систему финансовых транзакций на COBOL. Да, COBOL. Язык, о котором все говорят, что он мёртв. Знаете что? Согласно различным источникам, более 70% финансовых транзакций всё ещё выполняются на COBOL. Эти учреждения не глупы — они прагматичны. Система работает. Она быстрая. Надёжная. И самое главное, у неё нет уязвимостей зависимостей в парсере JSON, потому что у неё нет парсера JSON.

Премия за предсказуемость

Современные системы любят удивлять вас. Тот захватывающий новый фреймворк, который вы интегрировали? В последней минорной версии произошли критические изменения. Облачный сервис, на котором вы работаете? Изменил модель биллинга. Ваше контейнерное приложение? Работает нормально, пока не столкнётесь с каким-нибудь малоизвестным ограничением ресурсов, о котором никто не документировал.

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

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

Скрытая экономика «древней» инфраструктуры

Здесь становится неудобно для сторонников модернизации. Давайте поговорим о реальных цифрах, а не только об абстрактных преимуществах.

Та устаревшая система, которая работает в вашем центре обработки данных? Она, вероятно, амортизирована. Это значит, что ваши бухгалтеры уже списали её. Она числится в ваших отчётах как полностью амортизированное имущество. Между тем, та блестящая новая миграция в облако, которую вы планируете? Это операционные расходы, съедающие вашу прибыль. Каждый месяц. Всегда.

Да, модернизация может снизить затраты — результаты поиска, которые я мог бы привести, показывают потенциальное снижение затрат на обслуживание на 30–50%. Но вот правда: это происходит только если вы всё делаете правильно. Большинство компаний тратят 18–36 месяцев и миллионы долларов на «проект модернизации», который в итоге обходится дороже, чем просто поддержка устаревшей системы ещё десятилетие.

Наиболее успешная устаревшая система — это часто та, которая требует минимального обслуживания, потому что она настолько проста и скучна, что никто не нуждается в её изменении. Это кодовый эквивалент ракеты «выстрелил и забыл». Настроил, забыл, проверяй раз в год, чтобы убедиться, что она всё ещё работает.

Когда ваша «устаревшая» система на самом деле является вашим конкурентным преимуществом

Институциональные знания и племенная мудрость

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

Современные системы? Каждый новый сотрудник должен уметь разбираться в них, потому что они построены с использованием популярных фреймворков и стандартных шаблонов. Это хорошо для масштабируемости. Но это также означает, что знания становятся товаром. Каждый может заменить каждого.

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

Надёжность, которой нет в блогах

Позвольте мне описать реальную картину. Ваша устаревшая мейнфреймовая система обрабатывает 50 миллионов транзакций в день. Она делает это уже 15 лет. Её время безотказной работы составляет 99,97%.

Новая система микросервисов, которую вы строите? Она, вероятно, стремится к «пяти девяткам» — 99,999% времени безотказной работы. Звучит лучше, правда? Вот в чём дело: достижение более высокого времени безотказной работы на более сложных системах с большим количеством движущихся частей обходится дорого. Вам нужно лучшее мониторинг, больше резервирования, больше инфраструктуры. Ваша устаревшая система достигает своей надёжности за счёт простоты. У неё меньше вещей, которые могут сломаться.

graph TD A["Сложность устаревшей системы"] -->|Простая, проверенная| B["Высокая надёжность"] C["Сложность современной системы"] -->|Больше компонентов, больше точек отказа| D["Требуется обширная инфраструктура
для достижения такой же надёжности"] B -->|Годы производственного опыта| E["Проверенный в бою код"] D -->|Мониторинг, резервирование, инфраструктура| F["Усилия инженеров и затраты"]

Производительность, которая удивляет всех

Вот шутка в отрасли: лучшая оптимизация — это та, которую вам не нужно делать. Устаревшие системы часто удивляют людей, потому что они уже прошли несколько этапов оптимизации. Тот запрос к базе данных из 1998 года? Он был настроен. Тот алгоритм, эффективный по памяти, который никто не трогает? Он оптимален, потому что кто-то на горьком опыте узнал, что происходит, когда вы делаете его менее оптимальным.

Я видел, как «современные» реализации значительно уступали устаревшим системам, потому что в устаревшем коде были применены двадцать лет оптимизации инженерами, которым приходилось уместить всё в 4 МБ ОЗУ и процессор с частотой 800 МГц.

Правдивый рассказ: подлинные недостатки (да, они существуют)

Я не собираюсь вводить вас в заблуждение — у устаревших систем есть реальные проблемы. Давайте будем честными:

  • Набор талантов: удачи в поиске человека, который хочет посвятить свою карьеру COBOL или поддержке системы баз данных 1980-х годов. Молодые инженеры хотят работать с модными технологиями.
  • Скорость добавления функций: добавление новых функций в устаревшие системы похоже на попытку танцевать в трёхчастном костюме. Возможно, но не элегантно.
  • Кошмар интеграции: подключение вашей устаревшей системы к современным API и сервисам требует слоёв адаптеров и промежуточного программного обеспечения.
  • Угроза безопасности: старым системам часто не хватает современных фреймворков безопасности, а установка исправлений может быть сложной или невозможной. Это реальные проблемы. Они важны. Они не вся история.

Практическая рамка: когда сохранять, когда модернизировать

Вот моё мнение: большинство компаний неправильно принимают решение о модернизации.

graph LR A["Критическая система?"] -->|Да| B["Обрабатывает основной доход?"] A -->|Нет| C["Утилизировать или заменить"] B -->|Да| D["Затраты на обслуживание <5% бюджета ИТ?"] B -->|Нет| E["Планировать модернизацию"] D -->|Да| F["Продолжать оптимизацию
Только стратегическое обслуживание"] D -->|Нет| G["Стратегическая миграция"]

Правда в том, что:

  • Если ваша устаревшая система обходится менее чем в 5% вашего бюджета на ИТ для обслуживания и она обрабатывает основной доход, вы выигрываете. Не чините то, что не сломано.
  • Если ваша устаревшая система обходится в 30% вашего бюджета на ИТ и заставляет вас нанимать дорогостоящих специалистов, да, модернизируйте.
  • Если ваша устаревшая система не позволяет добавлять функции, которые требуют клиенты, затраты на модернизацию могут оправдать увеличение дохода.

Контрарианский вывод

Промышленность утверждает, что все устаревшие системы — это злые динозавры, которых нужно убить и заменить облачными, контейнерными, основанными на микросервисах, бессерверными решениями. Этот нарратив отлично подходит для рекламных презентаций консалтинговых фирм и поставщиков облачных