Микросервисы или монолит: что выбрать бизнесу

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

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

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

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

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

Когда монолит — правильный выбор

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

• Стартап и MVP. Пока вы проверяете гипотезу, требования меняются каждую неделю. В монолите проще менять контракты между модулями — это просто рефакторинг, а не переговоры между сервисами по сети.
• Небольшая команда. Если над проектом работают 2–6 разработчиков, дробить продукт на сервисы попросту некому обслуживать.
• Предсказуемая нагрузка. Корпоративный портал, CRM, маркетплейс на старте, внутренняя система учёта — здесь монолит держит нагрузку годами.
• Ограниченный бюджет на DevOps. Монолит можно запустить на одном-двух серверах без Kubernetes, без service mesh и без отдельного инженера по инфраструктуре.

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

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

• Несколько независимых команд. Когда над продуктом работают 4+ команды и они мешают друг другу в одном репозитории, разделение по сервисам снимает конфликты релизов.
• Разная нагрузка на разные части. Если модуль уведомлений или поиска нагружен в десятки раз сильнее остального, его выгодно масштабировать отдельно, а не клонировать весь монолит.
• Разные требования к надёжности. Платёжный контур должен жить даже если упал модуль аналитики — изоляция сервисов это обеспечивает.
• Разные технологии. Когда одной части нужен Python для ML, а другой — высокая скорость на Go, сервисы позволяют не смешивать стеки.

Важно: ни один из этих пунктов не про «модно» и не про «на вырост». Это конкретные ограничения, которые вы реально упёрлись в продакшене.

Сколько это стоит на самом деле

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

На рынке Узбекистана это особенно чувствительно: квалифицированных DevOps- и SRE-специалистов мало, и они дороги. Часть продуктов вынуждена держать инфраструктуру за рубежом из-за требований к латентности или доступности облачных сервисов, что добавляет расходы и сложность сопровождения. Микросервисная архитектура без зрелой команды эксплуатации превращается в постоянный источник простоев и счетов.

Главная ошибка: преждевременное дробление

Самая частая и самая дорогая ошибка — спроектировать систему как десяток микросервисов до того, как появился продукт и понимание предметной области.

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

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

Как принять решение в вашем случае

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