Монолит или микросервисы: чек-лист выбора архитектуры

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

Сначала отделите неудобство от архитектурной проблемы

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

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

Микросервисы покупают независимость релизов ценой распределённой системы. Если независимость вам не нужна, вы платите за сложность, не получая главной выгоды.

Три варианта и их цена

Модульный монолит — не обязательная ступень к микросервисам. Это самостоятельный выбор: сохранить простоту одного развёртываемого приложения, но не превращать его в набор взаимозависимых частей.

Чек-лист перед решением

1. Назовите проблему одним предложением. Например: «Команда каталога не может выпускать изменения без синхронного релиза оформления». Формулировка «монолит разросся» слишком расплывчата. Проверка: проблема подтверждается примерами задач или релизов, а не только ощущением.
2. Проверьте границы ответственности. У частей системы должны быть понятные владельцы и относительно устойчивые правила взаимодействия. Если любое изменение требует правок в нескольких командах, извлечение сервиса может закрепить неверное разделение. Проверка: вы можете описать ответственность каждого кандидата без формулировки «всё, что касается…».
3. Оцените независимость выпуска. Спросите, действительно ли компонент должен выходить отдельно, и что мешает это делать сейчас. Проверка: у команды есть отдельная потребность в релизах, а не просто желание иметь отдельный репозиторий.
4. Посчитайте операционную готовность. Для сервиса нужны сборка и развёртывание, мониторинг, логи, оповещения, управление конфигурацией и понятная ответственность за сбой. Проверка: команда знает, кто обнаружит проблему и как найдёт её источник, если запрос прошёл через несколько компонентов.
5. Разберите данные и отказы. При разделении могут понадобиться сетевые запросы между частями, а единая операция — например, оформление заказа — может затрагивать несколько компонентов. Проверка: описан сценарий частичного отказа и понятно, что увидит пользователь.
6. Сравните стоимость поддержки. Учитывайте не только время разработки, но и сопровождение сборок, тестов, развёртываний и инцидентов. Проверка: переход решает названную проблему, а ожидаемая экономия не опирается на предположение, что новая инфраструктура бесплатна.

Как читать результат

Оставайтесь на монолите

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

Укрепляйте модульный монолит

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

Выносите сервис, когда есть конкретная причина

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

Универсального безопасного числа команд, пользователей или строк кода, после которого пора переходить на микросервисы, нет. Если у вас пока нет данных, замерьте частоту релизов, время от готовности изменения до выпуска, долю релизов с откатом и время восстановления после сбоя. Сравнивайте показатели до и после изменений на сопоставимом промежутке, а не по одному удачному релизу.

Граница сервиса¹ — это договорённость о том, какие данные и ответственность принадлежат компоненту, а через какой интерфейс с ним взаимодействуют остальные части системы. Плохая граница заставляет команды часто менять несколько сервисов ради одной функции.

Что делать дальше

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