Building Evolutionary Architectures — выпуск 1

Ведущие напоминают, что клуб собирается примерно с 2021 года и берётся уже за шестую или седьмую книгу: читают по главам, обсуждают ключевые идеи и вспоминают истории из личного опыта; заодно советуют Telegram-канал Александра с короткими книжными обзорами. Сергея Баранова ждали в эфире, но подвёл форс-мажор — ему желают здоровья и обещают в следующем выпуске. Читают второе издание: в первом, насколько помнит один из ведущих, Прамода среди авторов не было, и, видимо, во втором добавились главы про данные, потому что он появляется именно в таких изданиях. Сменился и подзаголовок — вместо support constant change авторы вводят слово automatic. Похоже, между изданиями они поняли, что их история про эволюционность пересекается с governance: эта функция существовала в IT и раньше, тоже была про управление развитием систем, просто звучала не так модно.

Примеров в первом издании было заметно меньше, но за прошедшие шесть лет многое стало выглядеть очевидным. В книге девять глав: раньше это был плоский список, теперь появились три части — механика, структура и импакт. В первой собраны ключевые особенности и практики, во второй — архитектурные решения, помогающие поддерживать эволюционность, в третьей — влияние окружения, потому что ничего не происходит в изоляции. Клуб поделил книгу на шесть эфиров и начинает с механики. Участники отмечают любовь авторов к терминологии: архитектурные кванты, по памяти одного из ведущих, пришли из «Fundamentals of Software Architecture» того же Форда, а connascence — не их изобретение, авторы ссылаются на книгу примерно 1993 года. Один из ведущих вспоминает, как в 2019 году долго искал, откуда взялся термин: он настолько редкий, что это скорее ренессанс. Разбирать его будут в следующий раз.

Первая глава начинается с очевидного: построить архитектуру, которая сразу будет прекрасно жить, не доставлять проблем и красиво стареть, невозможно или очень сложно — её придётся постоянно обновлять. Участникам нравится, что развитие систем авторы объясняют через бизнес: до двухтысячных всё упиралось в ресурсы машины, потом Linux и open source переманили бизнес, оказавшись выгоднее, а следом пришли контейнеризация и мелкие части, переродившиеся в микросервисы. Прийти условно в 1999 году с идеей распилить систему на микросервисы и попросить сто машин со ста лицензиями — и бизнес отправит подальше: на одной машине дешевле и проще. Один из ведущих напоминает, что так же подробно клуб разбирал эволюцию в новогоднем выпуске по манифесту Amazon: как компания на рубеже веков съезжала с Sun на обычные серверы и как из этого выросла отдельная бизнес-модель.

Другой участник вспоминает статьи о том, что в Amazon часть сервисов переписывают обратно в более монолитные приложения и поднимают утилизацию процентов на девяносто; ему возражают, что там история скорее про инструменты: Step Functions, Lambda и S3 стали молотком, которым забивают гвозди даже там, где нужен шуруп, — забили быстро, потом подумали, вытащили и вкрутили другое. Определение авторов: эволюционная архитектура поддерживает управляемые инкрементальные изменения в нескольких измерениях. Архитектурные характеристики они сознательно не сводят к нефункциональным требованиям и атрибутам качества — старые имена, по их мнению, описывают не всё. Измерений в примерах четыре: техника и фреймворки, данные, безопасность и операционная часть; на схеме в центре доменные требования с unit-, интеграционными и функциональными тестами, а вокруг performance, auditability, legal и данные. Список не закрыт: значимое именно для вашего продукта можно смело заносить туда же. Один из участников вспоминает интервью авторов: когда идею эволюционной архитектуры рассказали впервые, им ответили, что они ничего не понимают, ведь архитектура — это то, что никогда не меняется.

Фитнес-функция показывает, насколько текущий дизайн близок к поставленной цели: она ловит случайные изменения и одновременно позволяет менять архитектуру осознанно — подкрутил функцию и смотришь, как система подходит под обновлённые требования. Название пришло из эволюционных вычислений, которыми занимался один из авторов: там фитнес-функция решает, сохранить мутировавший экземпляр или отбросить. Метафора рабочая — архитектура должна быть настолько здоровой, чтобы система не ушла на второй или третий цикл полного переписывания. Инструменты авторы перечисляют разные: мониторинг, где ценна не метрика, а доведённый до алерта сигнал; статические анализаторы сложности кода; хаос-инжиниринг с выключением куска дата-центра, который иногда проще проводить вручную; анализаторы, ловящие уязвимую библиотеку в зависимостях. Под архитектурные проверки, по предположению участника, авторы намекают на ArchUnit или JDepend. Категории фитнес-функций участникам не понравились: пользы, кроме иллюстративной, в них немного.

Зато полезно помнить, что функции бывают по триггеру, постоянные и ручные, и что складывать всё в один фреймворк не стоит. Практику приносит история одного из участников: около 2019 года его коллега, отвечавший за несколько команд, написал маленький фреймворк с DSL для описания правил. Нашли уязвимость — ставишь правило с дедлайном в неделю: пайплайн неделю ругается предупреждениями, а потом просто не даёт зарелизиться, пока зависимости не подняты. Но к автоматической проверке, подчёркивает он, обязательно нужны ссылка с объяснением и живая коммуникация. Главу про инкрементальные изменения держит один пример — сервис рейтингов, который разбирается чуть ли не трижды. Авторы предлагают автоматически выводить из продакшена сервис без трафика; участники сомневаются: без дедлайнов старый сервис остаётся зомби, а если потребителей не два, как на картинке, а две тысячи, непонятно, сколько уйдёт времени. Деплой-пайплайн проходят быстро: атомарные фитнес-функции после функциональных тестов, холистические ближе к проду, фича-флаги и скепсис про Pact, который красиво звучит, но в жизни быстро затухает. В следующий раз — четвёртая глава.