Монолит против микросервисов для первых 20 инженеров

Почему этот выбор важен до 20 инженеров

Спор «монолит против микросервисов» перестаёт быть абстрактным в тот момент, когда команда начинает платить за него в повседневной работе. Один плохой релиз может вывести продукт из строя. Один новый сотрудник может месяцы разбираться, как всё устроено. Одна небольшая фича может превратиться в неделю координации.

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

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

Стадия команды важнее следования трендам. Команда из 3 инженеров имеет совсем другие проблемы, чем команда из 12, даже если обе хотят тот же будущий масштаб. Малые команды обычно теряют больше времени на координацию, чем на ограничения системы. Им нужна архитектура, которую можно понять в 2 часа ночи при инциденте, а не та, что красиво смотрится на диаграмме.

Для команд до 10 инженеров главный риск часто — самодельная сложность. Набор множества сервисов может породить сетевые проблемы, рассинхронизацию версий, дублирование инструментов и размытое владение задолго до реальной нагрузки. У монолита свои проблемы, но на таком этапе его часто легче читать, тестировать и исправлять.

Ближе к 20 инженерам давление меняется. Больше людей вносят правки в один и тот же код. Конфликты релизов растут. Одна команда может блокировать другую. Границы доменов начинают иметь большее значение. Тогда вопрос уже не про моду — а про то, соответствует ли текущая структура тому, как команда работает.

Если ваша команда где‑то между 3 и 20 инженеров, не ищите единственного верного ответа навсегда. Ищите компромисс, который подходит сейчас, и периодически пересматривайте решение по мере роста команды.

Когда монолит подходит лучше всего

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

Если после изменения ценника ломается checkout, инженеры могут посмотреть один репозиторий, один набор логов и один релиз. Это звучит просто, потому что так и есть. Ранним командам нужна прямая связь между изменением и результатом.

Это также упрощает найм. Новый инженер изучает одно приложение, один путь деплоя и один поток тестов. Он может исправлять баги и выпускать фичи быстрее, потому что не нужно в первый же день разбирать границы сервисов, контракты API, ошибки очередей и межсервисную авторизацию.

Одна база данных помогает больше, чем многие ожидают. Отчёты проще писать. Транзакции легче анализировать. Когда спрашивают: «Какие пользователи оплатили, а потом отменили в течение 30 дней?», ответ часто получается одним запросом, а не цепочкой синхронизаций и полу‑совпадающих копий данных.

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

Монолит часто правильный выбор, когда одна команда по‑прежнему владеет большинством фич, продукт меняется часто, данные проходят через многие функции в одном пользовательском потоке, и одно приложение может справляться с трафиком при обычном масштабировании.

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

На первом этапе роста скучная архитектура часто оказывается умным решением.

Когда микросервисы начинают иметь смысл

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

Разделение помогает, когда одна область развивается заметно быстрее остальных. Возможно, ядро продукта меняется каждую неделю, а биллинг почти не меняется. Или основной сайт спокоен, а фоновая задача по обработке файлов или AI постоянно меняется. В таких случаях вынуждать обе части жить в одном цикле релизов создаёт ненужное трение.

Признаки, что граница реальна

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

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

Масштабирование тоже может оправдать разделение, но только в узких случаях. Если одна нагрузка резко превосходит остальные, отдельный деплой может сэкономить деньги и снизить стресс. Обычное веб‑приложение с pipeline по обработке документов, который обрабатывает в десять раз больше задач в конце месяца, — хороший пример. Такой pipeline может заслуживать своего сервиса. Остальная система — нет.

Цена преждевременного разделения

Каждый новый сервис добавляет сетевые вызовы, контракты API, шаги деплоя, логи, алерты и точки отказа. Баг, который раньше был вызовом функции, может превратиться в таймаут, цикл повторов или рассинхронизированные данные между сервисами.

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

Как ошибки распространяются в каждой модели

Монолит обычно ломается громко и очевидно. Один плохой деплой, одна утечка памяти или неудачная миграция БД могут вывести большую часть приложения. Это больно, но преимущество — ясность. Команда видит один инцидент, открывает одну кодовую базу и принимает одно решение об откате.

Отказы в монолите

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

Простой пример: плохой релиз изменил способ хранения сессий пользователей. Вдруг checkout, страницы админки и настройки аккаунта перестали работать. Это неприятно, но исправление обычно прямое: откат релиза, восстановление старого поведения и разбор бага после стабилизации сайта.

Отказы в микросервисах

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

Это сильно усложняет отладку. Вместо одного процесса и одного потока логов команде может понадобиться проследить запрос через пять сервисов, очередь сообщений и две версии одного и того же API. Рассинхронизация версий ухудшает ситуацию. Сервис A ожидает одно поле. Сервис B перестал его посылать на прошлой неделе. Теперь падают только некоторые запросы.

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

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

Как выглядят затраты на найм

Архитектура меняет затраты на найм задолго до того, как численность достигнет 20. Счёт — не только зарплаты. Это время обучения, нагрузка on‑call, более тяжёлые интервью и число людей, нужных прежде, чем работа станет спокойной.

Монолит обычно позволяет сначала нанимать сильных универсалов. На практике это дешевле. Один хороший инженер может исправить баг в checkout, добавить экран в админку, проверить изменение БД и выпустить всё в течение одной недели. Специалистов можно привлечь позже, а пока продукт быстро меняется — универсалы чаще выигрывают.

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

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

Нагрузка on‑call — место, где многие команды чувствуют боль первыми. В монолите один процесс деплоя и один путь алертов покрывают многое. В микросервисах у каждого сервиса свои правила, дашборды и особенности. Даже если отдельный сервис маленький, суммарный операционный шум утомляет. Тогда либо платите выгоранием, либо нанимаете раньше.

Растут и затраты на обучение. Новый инженер часто может запустить монолит с одним репозиторием, одной базой и коротким гайдом. В микросервисной среде ему может понадобиться пять репозиториев, локальные контейнеры, тестовые данные, креденшалы сервисов и ментальная карта вызовов. То, что в монолите занимает полдня, в распределённой системе может потребовать недели, чтобы стать привычным.

Поэтому многие опытные CTO держат первую систему проще, чем подсказывает орг‑схема. Если у вас всего несколько инженеров, платить за универсалов обычно лучше, чем за оверхед распределённых систем.

Как меняется релизная боль при 5, 10 и 20 инженерах

Боль релизов меняет форму по мере роста команды. Решение для пяти инженеров отличается от решения для двадцати.

В команде из 5 человек обычно выигрывает единый релизный цикл. Все ещё знают большую часть кода, изменения касаются одних и тех же областей, и общий ритм снижает число сюрпризов. Если разделиться в сервисы слишком рано, вы часто меняете одну очередь на пять мелких. Теперь каждый релиз требует проверок версий, согласования API и больше отладки при проблемах кросс‑границ.

При ~10 инженерах монолит начинает казаться тяжёлым, но боль обычно появляется в рутинных вещах. Тесты выполняются слишком долго. Pull request'ы висят днями. Две команды редактируют одни и те же файлы. Это раздражает, но ещё не доказывает необходимость микросервисов. Многие команды получают реальное облегчение от ускорения CI, выбора тестов, ясного владения кодом, уменьшения ручных шагов релиза и более мелких деплоев.

К 20 инженерам владение становится важнее размера кода. Вы всё ещё можете выпускать из монолита, но только если команды знают, за что они отвечают, и могут менять свои области без ожидания трёх других групп.

Здесь границы сервисов могут помочь, но только если они совпадают с реальными командными границами. Если одна команда отвечает за биллинг, другая — за аутентификацию, третья — за аналитику, отдельные сервисы могут уменьшить коллизии релизов. Если домены всё ещё переплетены, сервисы просто прячут ту же неразбериху за сетевыми вызовами.

Боль при релизах — подсказка, а не приговор. Плохой процесс релизов может быть следствием слабых тестов, медленных сборок, неясного владения или слишком многих ручных передач.

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

Как принимать решение по шагам

Большинству команд помогает рассматривать это как серию небольших экспериментов, а не как одно архитектурное пари. Для молодого продукта направление обычно проясняется, если смотреть в порядке: изменения, отказы и боль релизов.

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

Потом посмотрите последние инциденты и медленные релизы. Опирайтесь на факты, а не мнения. Какой модуль ломается чаще всего? Какая область заставляет деплой длиться дольше из‑за вечных тестов, рискованных миграций или того, что две команды наступают друг другу на пальцы?

Простая таблица помогает:

1. Перечислите области продукта, которые менялись за последние 6–8 недель.
2. Отметьте те, что вызывали инциденты, откаты или долгие релизы.
3. Проверьте, нуждается ли какая‑то область в совсем другом масштабе, правилах данных или уровне доступности.
4. Если граница очевидна — вынесите сначала только её.
5. Измеряйте скорость релизов, частоту отказов и командное трение прежде, чем разделять дальше.

Третий шаг особенно важен. Граница сервиса имеет смысл, когда область действительно живёт по другим правилам. Возможно, публичный API требует более строгого SLA, чем внутренняя админка. Возможно, обработка файлов требует тяжёлого вычисления, а остальная часть приложения — нет. Возможно, правила работы с данными заставляют особое отношение к одной части системы. Если ничего этого нет, преждевременное разделение чаще приносит лишнюю работу, а не облегчение.

Держите первое разделение маленьким и скучным. Не делайте из всего приложения шесть сервисов потому, что так выглядит чище. Одной границы, например биллинга или обработки документов, достаточно, чтобы понять, облегчают ли отдельные деплои реальную боль.

Наблюдайте несколько недель. Стали ли релизы проще? Снизилась ли нагрузка на on‑call? Стала ли одна команда двигаться быстрее, не ухудшив возможности отладки? Если результат смешанный, оставьте остальное вместе.

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

Реалистичный пример команды

Представьте небольшую SaaS‑компанию с веб‑приложением для клиентов, потоком биллинга, админкой для поддержки и экраном отчётов по использованию и выручке. Команда стартует с 5 инженеров, растёт до 8.

В этом размере один репозиторий делает жизнь проще. Все могут запустить продукт локально, менять UI и бэкенд в одной ветке и выпустить исправление без четырёх pull request'ов в четырёх сервисах. Когда клиент жалуется на баг в биллинге, один инженер может проследить запрос от веб‑приложения до платежного кода и БД в одном коде. Это экономит время каждую неделю.

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

Перенесём ту же компанию к 15 инженерам. У продукта больше клиентов. Отчёты дольше генерируются. Ночные задания импортируют данные, строят сводки и рассылают письма. Это часто первое чистое разделение.

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

Аутентификация, биллинг и ядро продукта обычно остаются вместе дольше. Они часто меняются одновременно. Обновление цен может коснуться прав, лимитов планов, логики checkout и экранов аккаунта в одном релизе. Если эти части вынести слишком рано, небольшое изменение продукта превратится в координацию между командами.

Хороший первый шаг специально скучен: сохраняйте один репозиторий, один основной app и выносите шумные части только тогда, когда у них собственная рабочая нагрузка и ритм релизов.

Ошибки, которые быстро создают боль

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

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

Одна распространённая ошибка — разделять сервисы по орг‑шарту, а не по границам кода. «Growth‑сервис» или «бэкенд для мобильных» могут совпадать с текущими именами команд, но эти имена быстро меняются. Пользовательские потоки меняются медленнее. Если один путь регистрации затрагивает четыре сервиса, потому что четыре команды владеют кусочками, каждый релиз превратится в координацию.

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

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

Медленные деплои часто вызваны скучными проблемами. Сборки запускаются слишком часто. Миграции блокируют таблицы. Набор тестов расползается. CI‑джобы ждут в очереди. Исправьте это в первую очередь. Практические решения CI/CD и продуманные инфраструктурные выборы снимают много боли без полного переписывания.

После разделения владение становится ещё важнее. У каждого сервиса должен быть один ответственный или одна команда, которая следит за ошибками, обновляет зависимости и знает шаги отката. Если за сервисом никто не следит, он превращается в маленький брошенный монолит — только теперь с возможностью падать по сети.

Быстрые проверки и следующие шаги

Начните с того, что команда может сделать на этой неделе, а не с диаграммы, которая, как вы надеетесь, будет понятна позже. Лучшее решение часто то, которое ваша текущая команда может поддерживать без стресса.

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

Если на два–три вопроса ответ «нет», прекратите разговоры о большем переписывании. Почините острое место перед вами. Возможно, проблема в процессе релизов, а не в монолите. Может быть, логи слабые, локальная настройка занимает четыре часа, или только один человек понимает деплой.

Хороший следующий шаг — маленький и конкретный. Вынесите одну шумную фоновую задачу из приложения. Добавьте трассировку запросов в существующую кодовую базу. Очистите модульные границы внутри монолита. Эти шаги дадут больше информации, чем большой план миграции.

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

Внешний аудит может сэкономить месяцы. Тот, кто видел и стартап‑хаос, и продакшн‑масштаб, обычно скажет, реальна ли у вас проблема масштабирования или это просто небрежный процесс релизов. Oleg Sotnikov делает подобные консультации через oleg.is, особенно для стартапов и небольших команд, которым нужен практический второй взгляд, прежде чем предпринимать дорогое архитектурное решение.

Запишите одно изменение, одного владельца и один дедлайн на следующий квартал. Затем измерьте результат. Стали ли деплои безопаснее? Ускорился ли онбординг? Стало ли проще отлаживать инциденты? Эти ответы важнее ярлыка, который вы повесите на архитектуру.