Микросервисы vs монолит — тема, которая определяет успех IT-проекта. CTO стартапа с 50 000 активных пользователей убедил совет директоров мигрировать на микросервисы. Аргументы звучали железно: «монолит не масштабируется», «Netflix так работает», «нужна независимая доставка фич». Бюджет — 4 миллиона рублей, срок — 5 месяцев.
Через 8 месяцев реальность: бюджет превышен втрое, 4 из 12 запланированных сервисов не задеплоены, команда из 6 человек тратит 60% времени на инфраструктуру вместо бизнес-фич. Kubernetes-кластер потребляет 150 000 рублей в месяц — втрое больше прежнего сервера. А монолит, который «не масштабировался», за это время упал один раз — на 12 минут. Вопрос микросервисы vs монолит заслуживает детального анализа.
Эта история — не исключение. По нашим наблюдениям, 60-70% стартапов мигрируют на микросервисы преждевременно. Результат — distributed monolith: сложность распределённой системы без её преимуществ. В этой статье — честное сравнение микросервисы vs монолит по 12 параметрам, фреймворк принятия решения о миграции и модульный монолит как третий путь, о котором редко говорят.
Почему все хотят микросервисы: Netflix-эффект
Микросервисная архитектура стала мейнстримом после того, как Netflix, Amazon и Uber рассказали о своём опыте на конференциях. Однако контекст этих историй часто игнорируется:
- Netflix перешёл на микросервисы при 1 000+ инженерах и сотнях миллионов пользователей. У них 700+ сервисов — и отдельная platform-команда из 200 человек, которая поддерживает инфраструктуру
- Amazon ввёл правило two-pizza teams (5-8 человек на сервис) при 10 000+ разработчиках. Их инфраструктура — это AWS, которую они буквально построили для себя
- Uber мигрировал при 2 000+ инженерах и начал с монолита, который обслуживал миллионы поездок в день
Общий паттерн: компании переходили на микросервисы, когда монолит действительно стал узким местом — при сотнях разработчиков и миллионах пользователей. Не при пяти инженерах и десяти тысячах MAU.
Тем не менее, на собеседованиях спрашивают про микросервисы, на конференциях рассказывают про микросервисы, в вакансиях требуют опыт с микросервисами. Возникает cargo cult: команды копируют архитектуру Netflix, не имея ни его масштаба, ни его ресурсов. Вопрос микросервисы или монолит превращается из инженерного в идеологический. Именно микросервисы vs монолит определяет результат для бизнеса.
Монолит vs микросервисы: сравнение по 12 параметрам
Вместо абстрактных рассуждений — конкретное сравнение. Каждый параметр имеет значение при принятии решения о миграции.
| Параметр | Монолит | Микросервисы | Кому важно |
|---|---|---|---|
| Время старта проекта | Быстро: один репозиторий, один деплой, одна БД | Медленно: настройка инфраструктуры 2-4 недели до первой строки бизнес-кода | Стартапам, MVP |
| Скорость разработки (малая команда) | Высокая: нет межсервисного overhead | Низкая: 30-40% времени на инфраструктуру | Команды до 10 человек |
| Скорость разработки (большая команда) | Падает: merge-конфликты, связанные модули, очередь на деплой | Высокая: команды деплоят независимо | Команды от 30+ человек |
| Масштабирование | Только вертикальное или полное горизонтальное (весь контур) | Гранулярное: каждый сервис масштабируется отдельно | Высоконагруженные системы |
| Стоимость инфраструктуры | 30-60 тыс. руб./мес. (1-2 сервера) | 150-300 тыс. руб./мес. (Kubernetes, мониторинг, service mesh) | Всем, у кого ограничен бюджет |
| Частота деплоя | 1-4 раза в неделю (весь контур) | Несколько раз в день на сервис | Продуктам с частыми релизами |
| Устойчивость к сбоям | Один баг может положить всё | Сбой сервиса изолирован (при правильном circuit breaker) | Критичным бизнес-системам |
| Сложность отладки | Простая: один процесс, один лог, один стектрейс | Высокая: distributed tracing, корреляция логов, network latency | Всей команде разработки |
| Консистентность данных | ACID-транзакции в одной БД | Eventual consistency, саги, компенсирующие транзакции | Финтех, e-commerce |
| Технологическое разнообразие | Один стек для всего | Каждый сервис — на оптимальном стеке | Командам с разной экспертизой |
| DevOps-требования | Минимальные: CI/CD для одного артефакта | Высокие: CI/CD на каждый сервис, Kubernetes, мониторинг, алертинг | Всем, кто планирует миграцию |
| Стоимость команды (в год) | 3-7 разработчиков + 0-1 DevOps | 15-25 разработчиков + 2-3 DevOps + platform team | CFO и CTO |
Обратите внимание: микросервисы выигрывают по 4 из 12 параметров, и все четыре актуальны только при большой команде и высокой нагрузке. Для большинства продуктов монолит — объективно лучший выбор по 8 из 12 критериев. Вопрос микросервисы vs монолит — не вопрос «что лучше», а вопрос «что подходит вашему продукту на текущей стадии».
Модульный монолит: третий путь, о котором молчат евангелисты
Между классическим монолитом и микросервисами существует архитектура, которая берёт лучшее от обоих подходов — модульный монолит.
Суть: код разбит на изолированные модули с чёткими интерфейсами (как микросервисы), но деплоится как единое приложение (как монолит). Каждый модуль имеет свою доменную логику, свои API-контракты и может общаться с другими модулями только через определённые интерфейсы — никаких прямых обращений к чужим таблицам или внутренним классам.
Что это даёт на практике:
- Простота инфраструктуры — один сервер, одна база, один деплой. Стоимость — как у монолита (30-60 тыс. руб./мес.)
- Изоляция модулей — изменения в модуле «Оплата» не ломают модуль «Каталог». Команды работают параллельно
- Готовность к декомпозиции — когда нагрузка или команда вырастут, модуль можно вынести в отдельный сервис за 2-4 недели, а не за 2-4 месяца
- Нет проблем распределённых систем — ACID-транзакции, простая отладка, отсутствие network latency между модулями
Факт: Shopify — крупнейшая e-commerce платформа — работает на модульном монолите (Ruby on Rails) и обрабатывает миллиарды долларов транзакций. Они осознанно выбрали эту архитектуру вместо микросервисов, потому что она позволяет 3 000+ разработчиков работать в одном репозитории с изолированными модулями.
Модульный монолит — не «костыль» и не «промежуточный этап». Для продуктов с командой до 30-50 человек и нагрузкой до 10 000 RPS это оптимальная архитектура, которая закрывает 80% задач масштабирования при 20% сложности микросервисов. Именно с такой архитектурой мы строим MVP в Prime IT — модули изолированы с первого дня, и при необходимости любой из них можно вынести в отдельный сервис. Подробнее о том, как мы подходим к масштабированию продуктов, читайте в нашем разделе.
Фреймворк решения: когда переходить на микросервисы
Решение о миграции должно основываться на объективных критериях, а не на мнениях с конференций. Вот фреймворк из пяти пороговых значений:
1. Размер команды
Если в команде менее 10-12 инженеров — микросервисы создадут больше проблем, чем решат. Каждый разработчик будет поддерживать 2-3 сервиса плюс инфраструктуру, вместо того чтобы писать бизнес-логику. Правило Amazon (two-pizza team на сервис) означает, что для 5 сервисов нужно минимум 25-40 инженеров.
- <10 инженеров — монолит или модульный монолит. Безальтернативно
- 10-30 инженеров — модульный монолит, выносите только узкие места
- 30+ инженеров — микросервисы оправданы, если merge-конфликты и очередь на деплой тормозят команды
2. Нагрузка и масштабирование
Если монолит справляется с текущей нагрузкой и вертикальное масштабирование (мощнее сервер) ещё не исчерпано — мигрировать рано. Микросервисы нужны, когда разные модули требуют кардинально разного масштабирования: модуль поиска — 10 000 RPS, модуль оплаты — 100 RPS.
3. Частота деплоя
Если команда деплоит 1-2 раза в неделю и это устраивает бизнес — монолит справляется. Потребность в микросервисах возникает, когда нужно деплоить разные части системы несколько раз в день, и зависимости между модулями блокируют релизы.
4. Бюджет на инфраструктуру
Инфраструктура для 10 микросервисов стоит 150-300 тыс. руб./мес.: Kubernetes-кластер, мониторинг (Prometheus + Grafana), distributed tracing (Jaeger), service mesh (Istio), CI/CD на каждый сервис. Для монолита — 30-60 тыс. руб./мес. Разница — 1-3 млн рублей в год.
5. Зрелость DevOps
Микросервисы без зрелого DevOps — это хаос. Если у вас нет автоматизированного CI/CD, мониторинга, алертинга и практики infrastructure-as-code — начните с этого в рамках монолита. Микросервисы только усилят незрелость процессов.
Если вы набрали менее 3 из 5 пороговых значений — мигрировать рано. Потратьте ресурсы на улучшение текущей архитектуры. Подробнее о принятии стратегических решений о продукте мы писали в статье Масштабировать, пивотить или закрыть.
Если решили мигрировать: strangler fig pattern
Допустим, ваш продукт прошёл все пять пороговых значений. Как мигрировать, не останавливая бизнес?
Худший подход — «перепишем всё с нуля на микросервисах». Это замораживает разработку на 6-12 месяцев, и к моменту окончания миграции бизнес-требования уже изменились.
Правильный подход — strangler fig pattern (паттерн удушающей лианы). Новые фичи строятся как отдельные сервисы, старый монолит постепенно уменьшается. Название — по аналогии с лианой фикуса, которая обвивает дерево и со временем заменяет его.
Алгоритм миграции:
- Определите bounded contexts — выделите в монолите модули с чёткими границами. Если границы нечёткие — сначала рефакторинг в модульный монолит
- Выберите первый сервис — модуль с наибольшей нагрузкой или наибольшей частотой изменений. Не начинайте с auth — это критичный модуль с минимальным бизнес-импактом
- API gateway — поставьте прокси перед монолитом. Запросы к новому сервису маршрутизируются на него, остальные — на монолит
- Вынесите модуль — перенесите логику, данные и тесты. Запустите параллельно с монолитом. Сравните результаты (shadow traffic)
- Переключите трафик — 10% → 50% → 100%. При проблемах — мгновенный rollback на монолит через gateway
- Повторите для следующего модуля. Один модуль за 2-6 недель
Критически важно: не пытайтесь вынести все модули. Часто 2-3 сервиса покрывают 80% проблем масштабирования, а остальной монолит продолжает работать. Полная декомпозиция — это цель только для компаний с 100+ инженерами.
Ошибки, которые превращают миграцию в катастрофу
- Общая база данных — если два сервиса ходят в одну БД, вы получили distributed monolith. Каждый сервис — своё хранилище
- Синхронные цепочки вызовов — сервис A вызывает B, который вызывает C. Падение C роняет всю цепочку. Используйте асинхронные сообщения (Kafka, RabbitMQ) для некритичных операций
- Микросервисы по техническим слоям — «сервис базы данных», «сервис авторизации», «сервис логирования». Это не микросервисы, а горизонтальная декомпозиция. Делите по бизнес-доменам: «сервис платежей», «сервис каталога», «сервис доставки»
- Отсутствие мониторинга до миграции — если вы не мониторите монолит, как вы поймёте, что микросервис работает лучше?
Архитектура как инструмент, а не религия
Вопрос микросервисы vs монолит — это не вопрос «что современнее». Это инженерное решение, которое зависит от размера команды, нагрузки, бюджета и стадии продукта.
Ключевые выводы:
- Монолит — не антипаттерн. Это архитектура, которая объективно лучше для 95% стартапов и продуктов на ранней стадии. Успешные компании начинали с монолита и мигрировали, когда масштаб команды и нагрузки этого требовал
- Модульный монолит — оптимальный выбор для большинства. 80% преимуществ микросервисов при 20% сложности. Готовность к будущей декомпозиции без текущих затрат на распределённую инфраструктуру
- Микросервисы оправданы при 30+ инженерах, неравномерной нагрузке и потребности в независимом деплое. Если хотя бы один пункт не выполняется — мигрировать рано
- Strangler fig — единственный безопасный путь миграции. Полное переписывание — это рулетка с бюджетом и сроками
- Distributed monolith — худшее из двух миров. Если мигрируете без чётких bounded contexts — получите сложность распределённой системы без её преимуществ
В Prime IT мы строим MVP за 22 рабочих дня на модульной архитектуре: каждый модуль изолирован с первого дня, интерфейсы между модулями зафиксированы, и при необходимости любой модуль можно вынести в отдельный сервис. Это не «монолит, который потом придётся переписывать», а продуманная архитектура, которая растёт вместе с продуктом.
Стоите перед выбором архитектуры или планируете миграцию существующего продукта? Запишитесь на бесплатный Zoom-колл — разберём вашу ситуацию, оценим текущую архитектуру и определим оптимальный путь: оставить монолит, перейти на модульный монолит или вынести узкие места в микросервисы. Бюджет MVP — до 900 000 рублей с фиксированной ценой.
FAQ о микросервисах и монолите
При какой нагрузке монолит перестаёт справляться?
Нет универсального порога — всё зависит от архитектуры, стека и инфраструктуры. Хорошо написанный монолит на современном фреймворке выдерживает тысячи RPS. Сигналы проблем: невозможность масштабировать отдельный модуль (весь контур требует горизонтального масштабирования), деплой раз в 2-4 недели из-за взаимозависимостей, время сборки превышает 30 минут. Если вы упираетесь в потолок одного-двух модулей — выносите именно их, а не разбирайте всю систему.
Сколько стоит переход с монолита на микросервисы?
Полная миграция среднего продукта (10-20 модулей) занимает 6-18 месяцев и стоит 3-12 млн рублей в зависимости от сложности. Главная статья расходов — не код, а инфраструктура: Kubernetes, service mesh, мониторинг, CI/CD на каждый сервис. Strangler fig pattern снижает риски, но растягивает сроки. Для продуктов с оборотом до 50 млн рублей в год модульный монолит обходится в 3-5 раз дешевле и закрывает 80% задач масштабирования.
Что такое модульный монолит и чем он лучше микросервисов?
Модульный монолит — архитектура, где код разбит на изолированные модули с чёткими интерфейсами, но деплоится как единое приложение. Преимущества: простота инфраструктуры (один сервер, одна база, один деплой), скорость разработки малой командой, отсутствие проблем распределённых систем (eventual consistency, distributed tracing). При этом модули можно вынести в отдельные сервисы позже, когда нагрузка или команда вырастут. Shopify работает на модульном монолите при обороте в миллиарды долларов.
Какой минимальный размер команды нужен для микросервисов?
Правило Amazon — two-pizza team на каждый сервис (5-8 человек). Для архитектуры из 5-10 сервисов нужно минимум 15-25 инженеров, включая DevOps. Команде из 3-7 разработчиков микросервисы создадут overhead больше, чем пользы: каждый будет поддерживать 2-3 сервиса плюс инфраструктуру вместо того, чтобы писать бизнес-логику. До 10-12 инженеров модульный монолит — оптимальный выбор.
Можно ли построить MVP сразу на микросервисах?
Технически — да, практически — почти всегда нет. На стадии MVP границы доменов ещё не определены: вы не знаете, какие модули будут нагружены, какие изменятся, а какие исчезнут. Микросервисы на этой стадии фиксируют неправильные границы и увеличивают стоимость каждого пивота в 3-5 раз. Правильный подход: модульный монолит с чёткими интерфейсами между модулями. В Prime IT мы строим MVP именно так — за 22 рабочих дня с архитектурой, готовой к будущей декомпозиции.