Когда монолит действительно пора делить
Сервис вырос до сотни модулей, сборка занимает вечность, а схему базы уже никто не помещает в голове.
Кажется, пора переходить на микросервисы.
Но размер сам по себе — слабый архитектурный аргумент. Большой монолит может годами оставаться удобным. А пять маленьких сервисов — превратиться в распределённый монолит, который падает по частям, а релизится всё равно целиком.
Я бы смотрел не на количество строк кода, а на то, живут ли части системы по разным правилам.
Вот несколько признаков.
Разные причины изменений
Одна часть меняется из-за требований бухгалтерии, другая — из-за экспериментов продуктовой команды, третья — при подключении новых партнёров.
Если изменения регулярно затрагивают только одну область, а остальные приходится собирать, тестировать и выкатывать за компанию, внутри монолита уже появились самостоятельные контуры.
Разные профили нагрузки
Каталог в основном читает данные. Биллинг обрабатывает транзакции. Генерация отчётов создаёт тяжёлую фоновую нагрузку.
Масштабировать весь сервис ради одного горячего участка дорого и неудобно. Особенно когда отчёт за прошлый квартал начинает конкурировать за ресурсы с оформлением заказов.
Разная скорость релизов
Одна часть продукта требует нескольких релизов в день. Другая меняется раз в месяц и должна проходить длинный цикл проверок.
Общий релизный процесс заставляет либо тормозить быстрый контур, либо принимать лишний риск в стабильном. Разделение позволяет каждому двигаться в своём темпе.
Разные владельцы
Если у компонентов есть отдельные команды, свои планы и ответственность за результат, общий код часто превращается в территорию постоянных согласований.
Но здесь важна оговорка: отдельный репозиторий ещё не создаёт автономность. Команда должна иметь возможность изменить, протестировать и выпустить свою часть без координационного совещания со всеми соседями.
Независимые 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