Когда монолит действительно пора делить
Сервис вырос до сотни модулей, сборка занимает вечность, а схему базы уже никто не помещает в голове.
Кажется, пора переходить на микросервисы.
Но размер сам по себе — слабый архитектурный аргумент. Большой монолит может годами оставаться удобным. А пять маленьких сервисов — превратиться в распределённый монолит, который падает по частям, а релизится всё равно целиком.
Я бы смотрел не на количество строк кода, а на то, живут ли части системы по разным правилам.
Вот несколько признаков.
Разные причины изменений
Одна часть меняется из-за требований бухгалтерии, другая — из-за экспериментов продуктовой команды, третья — при подключении новых партнёров.
Если изменения регулярно затрагивают только одну область, а остальные приходится собирать, тестировать и выкатывать за компанию, внутри монолита уже появились самостоятельные контуры.
Разные профили нагрузки
Каталог в основном читает данные. Биллинг обрабатывает транзакции. Генерация отчётов создаёт тяжёлую фоновую нагрузку.
Масштабировать весь сервис ради одного горячего участка дорого и неудобно. Особенно когда отчёт за прошлый квартал начинает конкурировать за ресурсы с оформлением заказов.
Разная скорость релизов
Одна часть продукта требует нескольких релизов в день. Другая меняется раз в месяц и должна проходить длинный цикл проверок.
Общий релизный процесс заставляет либо тормозить быстрый контур, либо принимать лишний риск в стабильном. Разделение позволяет каждому двигаться в своём темпе.
Разные владельцы
Если у компонентов есть отдельные команды, свои планы и ответственность за результат, общий код часто превращается в территорию постоянных согласований.
Но здесь важна оговорка: отдельный репозиторий ещё не создаёт автономность. Команда должна иметь возможность изменить, протестировать и выпустить свою часть без координационного совещания со всеми соседями.
Независимые failure domains
Падение рекомендаций не должно мешать оформить заказ. Ошибка в генерации документов не должна останавливать авторизацию.
Если части системы имеют разную критичность и должны отказывать независимо, техническая граница начинает приносить реальную пользу.
При этом вынести код в отдельный процесс недостаточно. Если сервисы используют одну базу, синхронно вызывают друг друга по длинной цепочке и релизятся только согласованным набором, failure domain остаётся общим. Просто теперь у него появился HTTP.
Именно поэтому аргумент «микросервисы сейчас делают все» ничего не говорит об архитектуре.
Разделение добавляет сетевые ошибки, контракты, наблюдаемость, версионирование, сложные тесты и новые сценарии отказа. За эту сложность стоит платить только тогда, когда она покупает независимость.
Не потому, что сервис стал большим.
А потому, что его части меняются, нагружаются, выпускаются, управляются и ломаются по-разному.
Сервис вырос до сотни модулей, сборка занимает вечность, а схему базы уже никто не помещает в голове.
Кажется, пора переходить на микросервисы.
Но размер сам по себе — слабый архитектурный аргумент. Большой монолит может годами оставаться удобным. А пять маленьких сервисов — превратиться в распределённый монолит, который падает по частям, а релизится всё равно целиком.
Я бы смотрел не на количество строк кода, а на то, живут ли части системы по разным правилам.
Вот несколько признаков.
Разные причины изменений
Одна часть меняется из-за требований бухгалтерии, другая — из-за экспериментов продуктовой команды, третья — при подключении новых партнёров.
Если изменения регулярно затрагивают только одну область, а остальные приходится собирать, тестировать и выкатывать за компанию, внутри монолита уже появились самостоятельные контуры.
Разные профили нагрузки
Каталог в основном читает данные. Биллинг обрабатывает транзакции. Генерация отчётов создаёт тяжёлую фоновую нагрузку.
Масштабировать весь сервис ради одного горячего участка дорого и неудобно. Особенно когда отчёт за прошлый квартал начинает конкурировать за ресурсы с оформлением заказов.
Разная скорость релизов
Одна часть продукта требует нескольких релизов в день. Другая меняется раз в месяц и должна проходить длинный цикл проверок.
Общий релизный процесс заставляет либо тормозить быстрый контур, либо принимать лишний риск в стабильном. Разделение позволяет каждому двигаться в своём темпе.
Разные владельцы
Если у компонентов есть отдельные команды, свои планы и ответственность за результат, общий код часто превращается в территорию постоянных согласований.
Но здесь важна оговорка: отдельный репозиторий ещё не создаёт автономность. Команда должна иметь возможность изменить, протестировать и выпустить свою часть без координационного совещания со всеми соседями.
Независимые failure domains
Падение рекомендаций не должно мешать оформить заказ. Ошибка в генерации документов не должна останавливать авторизацию.
Если части системы имеют разную критичность и должны отказывать независимо, техническая граница начинает приносить реальную пользу.
При этом вынести код в отдельный процесс недостаточно. Если сервисы используют одну базу, синхронно вызывают друг друга по длинной цепочке и релизятся только согласованным набором, failure domain остаётся общим. Просто теперь у него появился HTTP.
Именно поэтому аргумент «микросервисы сейчас делают все» ничего не говорит об архитектуре.
Разделение добавляет сетевые ошибки, контракты, наблюдаемость, версионирование, сложные тесты и новые сценарии отказа. За эту сложность стоит платить только тогда, когда она покупает независимость.
Не потому, что сервис стал большим.
А потому, что его части меняются, нагружаются, выпускаются, управляются и ломаются по-разному.
❤1
Если всё требует решения тимлида, это не контроль. Это очередь
Есть команды, в которых тимлид нужен буквально для всего.
PR ждёт его ревью.
Архитектурное решение — его мнения.
Новая библиотека — одобрения.
Разработчик хочет изменить API и тоже ждёт, потому что непонятно, имеет ли он право решить это самостоятельно.
Снаружи такая система может выглядеть как сильный контроль качества.
Фактически тимлид просто превратился в бутылочное горлышко.
Пока он доступен, процесс ещё как-то работает. Стоит ему уйти в отпуск, заболеть или провести полдня на встречах — решения начинают скапливаться в очереди.
Это опасный сигнал.
Задача тимлида не в том, чтобы лично принимать максимальное количество решений. Задача — построить систему, в которой большую часть решений команда может принимать без него.
Для этого нужны не красивые слова про автономию, а несколько вполне конкретных вещей.
Понятные границы решений
Команда должна знать, что она может решать самостоятельно, а что требует обсуждения.
Например:
— изменения внутри архитектурной области можно делать без согласования с тимлидом;
— изменение публичного API требует отдельного обсуждения;
— технический долг до определённого объёма можно брать без эскалации.
Ownership и реальные полномочия
Если у зоны есть владелец, он должен иметь право принимать решения внутри неё.
Ответственность без полномочий — это не ownership, а декоративное назначение виноватого.
Принципы вместо постоянных approvals
Хорошие архитектурные принципы позволяют принять десятки решений без отдельного согласования каждого.
Не «спросите тимлида, какую библиотеку использовать», а понятные критерии выбора: поддержка, безопасность, совместимость, стоимость эксплуатации.
Ясные точки эскалации
Команда должна понимать, когда решение выходит за её границы:
— высокий риск;
— влияние на несколько команд;
— необратимые изменения;
— заметный рост стоимости поддержки;
— изменение внешних контрактов.
У тимлида при этом остаётся контроль.
Просто контроль смещается с каждого отдельного действия на качество системы принятия решений: понятны ли границы, назначены ли владельцы, работают ли принципы, вовремя ли команда эскалирует риски.
На мой взгляд, это один из главных признаков зрелой команды.
Если без тимлида ничего нельзя решить, команда не автономна.
У неё просто очень медленный API.
Есть команды, в которых тимлид нужен буквально для всего.
PR ждёт его ревью.
Архитектурное решение — его мнения.
Новая библиотека — одобрения.
Разработчик хочет изменить API и тоже ждёт, потому что непонятно, имеет ли он право решить это самостоятельно.
Снаружи такая система может выглядеть как сильный контроль качества.
Фактически тимлид просто превратился в бутылочное горлышко.
Пока он доступен, процесс ещё как-то работает. Стоит ему уйти в отпуск, заболеть или провести полдня на встречах — решения начинают скапливаться в очереди.
Это опасный сигнал.
Задача тимлида не в том, чтобы лично принимать максимальное количество решений. Задача — построить систему, в которой большую часть решений команда может принимать без него.
Для этого нужны не красивые слова про автономию, а несколько вполне конкретных вещей.
Понятные границы решений
Команда должна знать, что она может решать самостоятельно, а что требует обсуждения.
Например:
— изменения внутри архитектурной области можно делать без согласования с тимлидом;
— изменение публичного API требует отдельного обсуждения;
— технический долг до определённого объёма можно брать без эскалации.
Ownership и реальные полномочия
Если у зоны есть владелец, он должен иметь право принимать решения внутри неё.
Ответственность без полномочий — это не ownership, а декоративное назначение виноватого.
Принципы вместо постоянных approvals
Хорошие архитектурные принципы позволяют принять десятки решений без отдельного согласования каждого.
Не «спросите тимлида, какую библиотеку использовать», а понятные критерии выбора: поддержка, безопасность, совместимость, стоимость эксплуатации.
Ясные точки эскалации
Команда должна понимать, когда решение выходит за её границы:
— высокий риск;
— влияние на несколько команд;
— необратимые изменения;
— заметный рост стоимости поддержки;
— изменение внешних контрактов.
У тимлида при этом остаётся контроль.
Просто контроль смещается с каждого отдельного действия на качество системы принятия решений: понятны ли границы, назначены ли владельцы, работают ли принципы, вовремя ли команда эскалирует риски.
На мой взгляд, это один из главных признаков зрелой команды.
Если без тимлида ничего нельзя решить, команда не автономна.
У неё просто очень медленный API.
👍2
AI-ready кодовая база: почему не каждый проект готов к агентам
Подключить AI-агента к репозиторию технически несложно.
Сложнее сделать так, чтобы он не тратил большую часть времени на археологию: искал точку входа, угадывал контракты и пытался понять, почему странное решение трёхлетней давности нельзя просто удалить.
Не каждый проект готов к агентам.
Чтобы агент мог приносить пользу, кодовая база должна быть понятна не только людям, которые годами держат её контекст в голове.
Что для этого нужно:
— актуальная документация с командами запуска и описанием ключевых сценариев;
— тесты, которые проверяют поведение и быстро показывают, что именно сломалось;
— понятная структура проекта без десятка равноправных точек входа;
— небольшие модули с явными границами и ответственностью;
— наблюдаемость: логи, метрики, трассировка и диагностируемые ошибки;
— зафиксированные архитектурные решения;
— ADR с контекстом: какую проблему решали, какие варианты рассматривали и почему выбрали именно этот;
— Decision Log для менее масштабных, но важных договорённостей.
Всё это было полезно и до появления AI-агентов. Просто люди умеют компенсировать недостатки системы: спросить коллегу, вспомнить обсуждение в чате или осторожно не трогать подозрительный участок кода.
Агент такого скрытого контекста не видит.
Если структура запутана, он быстрее запутается. Если тестам нельзя доверять, он быстрее внесёт регрессию. Если решения нигде не записаны, он уверенно повторит уже отвергнутый вариант.
AI не делает плохой проект хорошим.
Он делает последствия плохого проекта заметнее.
Подключить AI-агента к репозиторию технически несложно.
Сложнее сделать так, чтобы он не тратил большую часть времени на археологию: искал точку входа, угадывал контракты и пытался понять, почему странное решение трёхлетней давности нельзя просто удалить.
Не каждый проект готов к агентам.
Чтобы агент мог приносить пользу, кодовая база должна быть понятна не только людям, которые годами держат её контекст в голове.
Что для этого нужно:
— актуальная документация с командами запуска и описанием ключевых сценариев;
— тесты, которые проверяют поведение и быстро показывают, что именно сломалось;
— понятная структура проекта без десятка равноправных точек входа;
— небольшие модули с явными границами и ответственностью;
— наблюдаемость: логи, метрики, трассировка и диагностируемые ошибки;
— зафиксированные архитектурные решения;
— ADR с контекстом: какую проблему решали, какие варианты рассматривали и почему выбрали именно этот;
— Decision Log для менее масштабных, но важных договорённостей.
Всё это было полезно и до появления AI-агентов. Просто люди умеют компенсировать недостатки системы: спросить коллегу, вспомнить обсуждение в чате или осторожно не трогать подозрительный участок кода.
Агент такого скрытого контекста не видит.
Если структура запутана, он быстрее запутается. Если тестам нельзя доверять, он быстрее внесёт регрессию. Если решения нигде не записаны, он уверенно повторит уже отвергнутый вариант.
AI не делает плохой проект хорошим.
Он делает последствия плохого проекта заметнее.
👍2❤1
Код работает. Но команда не понимает почему
PR принят. Тесты зелёные. Решение уже в проде.
Но через месяц появляется новое требование — и выясняется, что никто не хочет трогать этот код.
Не потому, что он плохо написан. Просто команда не может уверенно ответить:
— почему выбрали именно это решение;
— какие предположения в него заложены;
— где проходят его границы;
— что сломается при изменении требований.
AI заметно ускорил путь от задачи до работающего кода. Но вместе с этим появился новый вид долга — долг понимания, или comprehension debt.
Это не совсем обычный технический долг.
Технический долг обычно заметен: дублирование, сложные зависимости, отсутствие тестов, устаревшие библиотеки. А здесь код может выглядеть вполне прилично.
Проблема в другом: команда формально владеет решением, но фактически не понимает его достаточно хорошо, чтобы безопасно развивать.
Особенно опасна фраза:
Проверка результата не равна пониманию решения.
Как тимлиду не допустить накопления такого долга?
На ревью обсуждать не только код, но и решение:
1. Почему выбран этот подход?
2. Какие альтернативы рассматривались?
3. На каких предположениях всё держится?
4. Где решение перестанет работать?
5. Сможет ли автор объяснить его без ссылки на чат с AI?
Не каждый PR должен превращаться в архитектурный трактат. Но чем выше цена ошибки, тем важнее зафиксировать ход мысли: в описании PR, ADR, комментарии к тесту или короткой схеме.
AI может генерировать код быстрее, чем команда успевает строить его ментальную модель. Поэтому новая задача тимлида — следить не только за скоростью разработки и качеством кода, но и за тем, остаётся ли понимание внутри команды.
Потому что код, который никто не понимает, — это уже не ускорение.
Это отложенный инцидент.
PR принят. Тесты зелёные. Решение уже в проде.
Но через месяц появляется новое требование — и выясняется, что никто не хочет трогать этот код.
Не потому, что он плохо написан. Просто команда не может уверенно ответить:
— почему выбрали именно это решение;
— какие предположения в него заложены;
— где проходят его границы;
— что сломается при изменении требований.
AI заметно ускорил путь от задачи до работающего кода. Но вместе с этим появился новый вид долга — долг понимания, или comprehension debt.
Это не совсем обычный технический долг.
Технический долг обычно заметен: дублирование, сложные зависимости, отсутствие тестов, устаревшие библиотеки. А здесь код может выглядеть вполне прилично.
Проблема в другом: команда формально владеет решением, но фактически не понимает его достаточно хорошо, чтобы безопасно развивать.
Особенно опасна фраза:
«Это AI предложил, мы проверили — работает».
Проверка результата не равна пониманию решения.
Как тимлиду не допустить накопления такого долга?
На ревью обсуждать не только код, но и решение:
1. Почему выбран этот подход?
2. Какие альтернативы рассматривались?
3. На каких предположениях всё держится?
4. Где решение перестанет работать?
5. Сможет ли автор объяснить его без ссылки на чат с AI?
Не каждый PR должен превращаться в архитектурный трактат. Но чем выше цена ошибки, тем важнее зафиксировать ход мысли: в описании PR, ADR, комментарии к тесту или короткой схеме.
AI может генерировать код быстрее, чем команда успевает строить его ментальную модель. Поэтому новая задача тимлида — следить не только за скоростью разработки и качеством кода, но и за тем, остаётся ли понимание внутри команды.
Потому что код, который никто не понимает, — это уже не ускорение.
Это отложенный инцидент.
👍2❤1