Когда проект только начинается, вопрос архитектуры кажется второстепенным — главное, чтобы работало. Но проходит год-полтора, и оказывается, что выбранная структура либо помогает развиваться, либо мешает каждой новой фиче. Монолит и микросервисы — два подхода, о которых спорят так часто, что легко запутаться. Разберёмся спокойно: без модных лозунгов и без утверждения, что один из них «правильный».
Что такое монолит на самом деле
Монолит — это приложение, где весь код живёт в одном проекте и разворачивается как единое целое. Пользовательский интерфейс, бизнес-логика, работа с базой данных — всё внутри одной кодовой базы.
Слово «монолит» часто произносят с пренебрежением, будто это legacy из нулевых. На деле так устроены тысячи успешных продуктов: от внутренних корпоративных систем до крупных маркетплейсов на ранних этапах. Монолит — это не «плохо», это просто другой набор компромиссов.
Сильные стороны монолита
- Простота запуска. Один репозиторий, одна сборка, один сервер. Развернуть и отладить быстрее.
- Понятная отладка. Ошибка в одном месте — лог в одном месте. Не нужно собирать трассировку по пяти сервисам.
- Транзакции без боли. Данные в одной базе, согласованность обеспечивается штатными средствами СУБД.
- Дешевле на старте. Меньше инфраструктуры, меньше DevOps-нагрузки, ниже порог входа для команды.
Слабые места монолита
- При росте команды разработчики мешают друг другу: правки в одном файле, конфликты, долгие сборки.
- Масштабируется всё приложение целиком, даже если нагрузку создаёт только один модуль.
- Любое обновление — это релиз всего монолита, а не отдельной функции.
- Технологический стек зафиксирован: заменить язык или фреймворк части системы почти невозможно.
Микросервисы: что за этим стоит
Микросервисная архитектура разбивает систему на небольшие независимые сервисы, каждый со своей зоной ответственности и, часто, своей базой данных. Сервисы общаются друг с другом по сети — через HTTP, брокеры сообщений, gRPC.
Из этого сразу следует важное: микросервисы — это не про код, а про инфраструктуру. Разбить монолит на сервисы в коде относительно просто. Заставить их надёжно работать вместе — задача на порядок сложнее.
Где микросервисы выигрывают
- Независимое развёртывание. Обновляете один сервис — остальные не трогаете.
- Точечное масштабирование. Нагружен только сервис оплаты? Масштабируем его, а не всю систему.
- Автономные команды. Каждая группа владеет своими сервисами и релизит в своём темпе.
- Гибкость в технологиях. Для каждого сервиса можно выбрать подходящий инструмент.
Обратная сторона
- Распределённые транзакции, гонки данных и частичные сбои — реальность, с которой приходится жить.
- Сложная observability: логи, метрики, трейсинг нужно собирать в единую картину.
- Дороже инфраструктура: оркестрация, сервис-меш, CI/CD на каждый сервис.
- Выше требования к компетенциям команды — ошибиться здесь легко и больно.
Как выбрать: вопросы, которые стоит задать
Универсального ответа нет, но есть набор проверочных вопросов. Если хотя бы на половину честно отвечаете «нет» — скорее всего, вам нужен монолит.
- Насколько велика команда? До 10–15 разработчиков монолит обычно работает лучше: координация дешевле, чем межсервисные контракты.
- Есть ли реальные зоны с разной нагрузкой? Если один модуль требует в десять раз больше ресурсов — это аргумент за выделение сервиса.
- Готовы ли вы к DevOps-инвестициям? Микросервисы без зрелой инфраструктуры — путь к постоянным инцидентам.
- Как часто нужно релизить разные части? Если релизы общие и раз в неделю — независимость сервисов не даёт выгоды.
- Понимаете ли вы границы домена? Резать систему на сервисы, не разобравшись в предметной области, — гарантированный способ получить распределённый монолит.
Промежуточные варианты, о которых забывают
Выбор не бинарный. Между классическим монолитом и полным набором микросервисов есть рабочие ступени:
- Модульный монолит. Одно приложение, но с чёткими внутренними границами модулей. Позволяет позже выделить сервис без переписывания.
- Выделение отдельных сервисов. Ядро остаётся монолитом, а тяжёлые или быстро меняющиеся части выносятся отдельно.
- SOA-подход. Крупные сервисы по бизнес-домену вместо десятков мелких.
На практике большинство успешных историй — именно про эволюцию: начинали с монолита, а сервисы выделяли по мере появления конкретной боли, а не ради моды.
Что в итоге
Монолит — разумный выбор для новых продуктов, небольших команд и проектов с неясными требованиями. Микросервисы оправданы там, где есть масштаб: несколько команд, разные профили нагрузки, потребность в независимых релизах.
Главная ошибка — выбирать архитектуру по хайпу, а не по задаче. Хорошая новость: архитектура не высечена в камне. Если монолит написан аккуратно, с выделенными модулями, разбить его на сервисы позже вполне реально. Обратный путь — собирать микросервисы обратно в монолит — обычно гораздо дороже и болезненнее.
Спасибо, что разобрали без лозунгов. Я как раз из тех, кто заказывает разработку, и мне полезно было понять, что микросервисы — это в первую очередь инфраструктура, а не просто «разбить код на части». Раньше думала, что так можно почти бесплатно ускорить команду, теперь вижу, что на старте монолит часто дешевле и проще.
Я работал на проекте, где монолит начал тормозить релизы, но не уверен, что проблема была именно в архитектуре. Есть ли в практике студии какой-то порог, после которого монолит точно становится проблемой? Например, 8–10 человек в команде и релизы раз в неделю, или всё зависит от связанности модулей и данных?
Порог по людям — плохой ориентир. Я бы не назвал конкретное число: в практике чаще смотрим на частоту релизов, связанность модулей и то, сколько команд правит одни и те же данные. Если 8–10 человек работают над слабо связанными доменами и релизят независимо, монолит может жить долго; если все постоянно лезут в один модуль, микросервисы сами по себе не спасут.
У нас был обратный опыт: разнесли монолит на сервисы, но не решили вопрос с общей базой и транзакциями. В итоге получили распределённые сбои и отладку по логам пяти сервисов. Так что согласна с мыслью, что микросервисы — это больше про инфраструктуру и зрелость процессов, чем про модный код.