Монолит или микросервисы для команды из пяти человек: как выбрать
Монолит или микросервисы для команды из пяти человек? Используйте простые правила решения, опираясь на скорость релизов, планы найма, требования комплаенса и нагрузку поддержки.
Почему этот выбор кажется больше, чем есть на самом деле
Для команды из пяти человек архитектура — это не абстрактная дискуссия. Она меняет, кто от кого зависит каждую неделю. Если одному разработчику нужна помощь от владельца другого сервиса, чтобы выпустить небольшое исправление, команда сразу почувствует эту цену.
«Монолит или микросервисы» часто воспринимают как вопрос престижа. Обычно это не так. Лучше та конфигурация, которая позволяет вашей команде выпускать, отлаживать и поддерживать продукт с наименьшими тормозами.
Каждая дополнительная граница имеет свою цену. Отдельные сервисы означают больше репозиториев, больше деплоев, больше логов, больше алёртов и больше мест, где небольшое изменение может сломать систему. Эти расходы заметны сразу, даже когда трафик ещё небольшой, а продукт меняется каждую неделю.
Мода делает выбор масштабнее, чем он есть. Малые команды копируют компании с десятками инженеров, строгими аудит‑правилами или круглосуточной поддержкой, а потом удивляются, почему релизы замедлились. Простой монолит часто — лучший дефолт, потому что ежедневная работа остаётся в одном месте. Один кодбейс проще тестировать, проще объяснить новому сотруднику и проще править, когда в четверг после обеда клиент попросит неожиданное изменение.
Разделять можно позже, когда причина станет очевидной. Может быть, одна доменная область постоянно создаёт нагрузку поддержки. Может быть, ей нужны более жёсткие правила доступа. Может быть, команда действительно выросла в отдельные группы. Ранняя сложность труднее отменить, чем монолит, который стал чуть великоват.
Начните со скорости релизов
Когда команда мала, скорость релизов показывает правду. Она отражает, как работа движется сейчас, а не ту версию команды, которую вы надеетесь иметь через полгода.
Оглянитесь на последние 4–8 недель и посчитайте реальные релизы, не запланированные. Если один кодбейс позволяет вам выкатывать исправления и фичи несколько раз в неделю без серьёзных трений — защищайте это. Часто монолит выигрывает здесь, потому что есть один репозиторий, один путь тестирования и один путь деплоя.
Потом ищите повторяющиеся блокеры. Задержала ли изменение в платёжном модуле исправление поиска? Блокировала ли одна рискованная зона несвязанную работу более одного раза? Одна плохая неделя много не значит. Важна закономерность.
Разделение начинает иметь смысл, когда одна и та же часть продукта постоянно замедляет работу, не связанную с ней. Возможно, этой области нужен собственный ритм релизов, правила утверждения или режим поддержки. Если она ещё и порождает срочные инциденты — аргумент становится сильнее.
Малые команды часто спешат обвинять архитектуру. На деле проблема — нестабильный тест‑набор, перегруженный ревьювер или размытость ответственности. Если вы не можете указать конкретную часть продукта, которая постоянно блокирует несвязанные релизы, не делите её пока.
Часто задаваемые вопросы
Стоит ли команде из пяти человек начинать с микросервисов?
Обычно нет. Начинайте с монолита: один репозиторий, один путь тестирования и один путь деплоя позволяют небольшой команде быстрее выпускать и исправлять ошибки.
Вы всегда можете разделить систему позже, когда какая‑то часть продукта начнёт блокировать несвязанные изменения или создавать большую часть нагрузки поддержки.
Когда монолит перестаёт иметь смысл?
Разделяйте, когда вы видите повторяющуюся картину, а не после одного неудачного релиза. Если одна доменная область постоянно задерживает несвязанные изменения, требует других правил утверждения или вызывает повторяющиеся инциденты, её стоит вынести в отдельный сервис.
Если вы не можете чётко назвать такую проблему, оставайтесь на монолите.
Является ли трафик хорошей причиной для разделения приложения?
Нет, сам по себе трафик редко является достаточной причиной. Небольшие команды чаще ломаются не из‑за количества запросов, а потому что какая‑то часть приложения постоянно падает и отрывает людей от плановой работы.
Нагрузка поддержки даёт более полезный сигнал. Если одна функция постоянно падает, будит людей по ночам или вредят остальной части приложения, сначала изолируйте её.
Как скорость релизов должна влиять на решение?
Посмотрите на последние 4–8 недель и посчитайте реальные релизы. Если изменения попадают в прод несколько раз в неделю без сильных задержек, защитите этот процесс.
Если одна рискованная область регулярно задерживает несвязанные исправления, это реальная причина пересмотреть архитектуру.
Какой план найма поддерживает микросервисы?
Микросервисы лучше подходят, когда вы ожидаете отдельные группы с устойчивым владением. Каждая группа должна уметь справляться с изменениями кода, релизами, оповещениями и поддержкой своей области.
Если ваши следующие наймы по сути останутся универсалами, монолит обычно подходит лучше.
Означают ли правила комплаенса, что нам нужны отдельные сервисы?
Нет. Многие команды решают задачи комплаенса внутри монолита: жёсткие права доступа, чистые логи аудита и отдельный доступ к данным для чувствительных областей.
Отдельный сервис нужен только тогда, когда одна область действительно требует иных контролей или иного ритма релизов.
Что следует изолировать в первую очередь, если одна область постоянно создаёт проблемы?
Вынесите ту часть, которая мешает чаще всего. Биллинг, импорты, фоновые задания или поиск часто бывают первыми кандидатами, а не весь сервис целиком.
Для большинства команд один отдельный сервис остаётся управляемым. Шесть новых сервисов — это совсем другой уровень усилий по релизам и поддержке.
Как долго стоит придерживаться решения прежде чем менять его снова?
Остаться с выбранной моделью минимум на один квартал. Три месяца дают достаточно данных: частота релизов, число инцидентов, объём тикетов и сколько времени уходит на координацию.
Одно совещание или одна плохая неделя часто ведут к эмоциональным решениям.
Как не дать монолиту превратиться в свалку?
Держите жёсткие внутренние границы даже в одном кодбазе. Оформите «грязные» домены вроде биллинга в отдельные модули, ограничьте, кто может писать в чувствительные таблицы, и сделайте сильные тесты вокруг рискованных потоков.
Такая чистка облегчает повседневную работу и упрощает будущий вынос сервиса при необходимости.
Какие проблемы кажутся архитектурными, но на самом деле связаны с процессами?
Многие проблемы выглядят как архитектурные, но на деле — процессные: медленные ревью, нестабильные тесты, ручное QA, отсутствие данных для стейджинга и неясные зоны ответственности. Команды обвиняют структуру кода, потому что это видимая цель.
Почините рабочие процессы в первую очередь. Если те же два человека всё равно ревьюят всё и поддержка постоянно прерывает работу, новые сервисы не помогут.