Монолит vs микросервисы и проблема команды за этим

Почему этот спор возвращается снова и снова

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

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

Одна и та же жалоба может означать очень разную боль. Один инженер имеет в виду: «тесты идут 40 минут». Менеджер продукта — «любое мелкое изменение требует трёх команд». Поддержка — «релизы рискованные, поэтому исправления ждут до следующей недели». Всё это похоже на проблемы архитектуры, но на самом деле описывает разные узкие места.

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

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

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

Спор монолит vs микросервисы возвращается снова и снова, потому что он даёт стрессу аккуратную подпись. Боль реальна. Но причина часто не та, что кажется на первый взгляд.

Что часто скрывает спор о монолите

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

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

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

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

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

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

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

Какие вопросы задать, прежде чем менять систему

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

Начните с задержек. Команда может говорить, что деплой сложный, но на деле изменение может три дня лежать на ревью, потом ждать QA, потом ждать релиз-менеджера. Это не проблема структуры кода. Это проблема потока.

Задайте несколько прямых вопросов:

• Где обычное изменение перестаёт двигаться?
• Сколько людей должны его одобрить до релиза?
• Какие команды каждую неделю правят одни и те же файлы?
• Когда что-то ломается, сколько людей касается инцидента, прежде чем один человек починит проблему?
• Менялись ли команда, объём продукта или нагрузка от клиентов за последние 6–12 месяцев?

Ответы обычно указывают на вполне конкретную причину. Если три команды каждую неделю правят один и тот же billing module, боль может быть в размытой ответственности. Если каждый релиз требует одобрения от четырёх человек, новый сервис эту очередь не уберёт. Если инциденты прыгают от поддержки к backend, потом к infra и обратно, команда, скорее всего, не договорилась, кто владеет проблемой.

Изменения в размере команды тоже важны. Кодовая база, которая нормально работала для шести инженеров, может начать ощущаться тесной при двадцати. И обратное тоже верно. Система, разбитая на множество сервисов, может быть удобной для большой platform-команды, а потом стать тяжёлой, если компания сократится и тащить всё будут те же несколько человек.

Изменения в объёме продукта создают такое же давление. Продукт, который начинался с одного типа пользователей, теперь может включать админские инструменты, правила billing, partner API и кастомную enterprise-работу. Команды часто читают это как «с архитектурой что-то не так». Иногда это правда. Но иногда команда просто так и не изменила, как она планирует, проверяет и владеет работой.

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

Простой способ найти настоящую проблему

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

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

Помогает короткий чек-лист:

• Отметьте каждую команду, которая трогала фичу.
• Запишите каждое согласование и каждую передачу задачи.
• Обведите места, где работа останавливалась на день или больше.
• Коротко опишите, почему она остановилась.
• Разбейте каждую задержку на код, процесс или ответственность.

Последний шаг особенно важен. Команды первым делом винят архитектуру, потому что это кажется конкретным. Но многие задержки возникают из-за размытой ответственности, медленных согласований или фичи, которая проходит через слишком много команд. Если frontend ждёт backend, backend ждёт platform, а platform ждёт security, проблема редко бывает только в форме репозитория.

Допустим, простое обновление цен заняло 18 дней. Изменение кода заняло два. Ревью — один. Потом фича четыре дня ждала подтверждения от product, ещё три — изменения в базе данных от другой команды, и два дня ушло потому, что никто не знал, кто отвечает за release checklist. Это в первую очередь проблема устройства команды, а не структуры кода.

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

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

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

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

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

Одна feature-команда добавляет новый тип тарифа. Команда integrations меняет, как enterprise accounts сопоставляются с permissions. Команда onboarding подстраивает flow приглашений для крупного клиента. Ни одно из этих изменений по отдельности не выглядит драматично, но все они попадают в одни и те же части системы. Pull request’ы лежат дольше. Ревью становятся напряжёнными. Одно небольшое изменение ломает релиз другой команды.

Через несколько циклов даты релизов начинают плыть. Люди говорят, что проблема в монолите, потому что так боль получает простую подпись.

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

Решение часто менее драматично, чем переписывание. Одна команда получает чёткую ответственность за billing rules. Другая — за identity и access. Остальные команды больше не правят эти области напрямую и используют согласованные интерфейсы внутри той же кодовой базы. Компания также вводит правила ревью, чтобы финальное решение принимала владеющая команда.

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

Когда системе действительно нужна новая граница

Некоторые команды слишком рано винят монолит. Другие слишком долго держат один кодовый базу, хотя он уже берёт налог с каждого релиза.

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

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

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

Часто это начинается с модели данных. Одна общая схема может так крепко связать billing, customer support, reporting и настройку аккаунтов, что каждое изменение притягивает несколько процессов, которые должны были бы быть раздельными.

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

Это и есть закон Конвея на практике. Система по-прежнему отражает старую форму команды, даже если текущая топология говорит, что эти задачи должны идти отдельно.

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

Вот здесь спор монолит vs микросервисы становится настоящим архитектурным вопросом, а не дискуссией о стиле. Меняйте границу, когда разные бизнес-задачи требуют разной скорости релизов, разной изоляции сбоев и более чистой ответственности.

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

Ошибки, которые делают спор хуже

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

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

Копирование структуры вместо исправления команды

Спор монолит vs микросервисы часто становится хуже, когда лидеры копируют паттерны очень больших компаний. Продуктовая команда из 12 человек не строит архитектуру так же, как компания с 800 инженерами. Крупные компании могут позволить себе platform-команды, владение сервисами, внутренние инструменты и работу по надёжности на полный день. Меньшие команды обычно не могут, по крайней мере пока.

Небольшая SaaS-команда из восьми инженеров может в итоге получить шесть сервисов, три пути деплоя и никого, кто хочет дежурить. Это не масштабирование. Это накладные расходы.

Люди ещё и делят код, чтобы решить путаницу в ролях. Если backend, frontend и решения по продукту устроены хаотично, разбиение кода на большее число репозиториев это не исправит. Людям всё равно нужно решать, кто владеет фичей, кто может менять API и кто получит сигнал, если всё сломается. Закон Конвея здесь прямолинеен: системы копируют форму общения.

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

Скрытый счёт, который никто не закладывает

Поддержка — это место, где проявляются многие плохие архитектурные решения. Каждый новый сервис добавляет рутинную работу: следить за метриками и логами, разбирать алерты и дежурства, закрывать security-проблемы, поддерживать CI/CD и скрипты деплоя, а ещё отслеживать сбои через границы сервисов.

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

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

Быстрая проверка перед тем, как выбрать направление

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

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

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

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

Спросите, что изменится в следующем квартале, а не в далёком плане. Уберёт ли это передачу задач в ближайшие 90 дней? Если ответ туманный, пока оставьте систему проще.

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

Простой пример делает это очевидным. Растущая SaaS-команда из восьми инженеров хочет вынести billing в отдельный сервис. На бумаге это кажется чистым решением. На практике тот же клиентский сценарий всё равно требует изменений в web app, auth, админских инструментах и support-скриптах. Одна и та же команда владеет всем этим, и они и так выпускают монолит каждый день. Разделение добавит контракты, retries и дополнительные алерты, но не уберёт передачи задач.

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

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

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

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

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

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

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

Такой разбор не обязан быть тяжёлым. Oleg Sotnikov на oleg.is занимается такой работой как fractional CTO, опираясь на опыт стартапов, enterprise-систем и AI-first engineering-команд. Полезная часть здесь — не большой план переписывания. Полезно получить ясную картину устройства команды, потока релиза и того, где изменения архитектуры действительно помогут.

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