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

Что такое монолит

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

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

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

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

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

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

Главный минус — операционная сложность. Распределённая система — это сетевые задержки, eventual consistency, необходимость service discovery, circuit breakers, distributed tracing, centralized logging. Это отдельная инфраструктурная команда и значительные расходы на DevOps.

Стоимость владения

Монолит дешевле на старте. Один сервер, одна CI/CD-пайплайн, одна база. Хостинг монолита на средней VPS обойдётся в $20–50 в месяц. Для стартапа на стадии MVP — это разумный выбор.

Микросервисы дороже по всем параметрам: инфраструктура (Kubernetes-кластер, service mesh, мониторинг), время разработки (настройка межсервисной коммуникации, контракты API), операционные расходы (on-call для каждого сервиса, инцидент-менеджмент). Минимальный Kubernetes-кластер в облаке — $200–500 в месяц, и это только начало.

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

Производительность и масштабируемость

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

Микросервисы масштабируются точечно. Сервис поиска обрабатывает 10 000 запросов в секунду — запускаем 20 реплик. Сервис настроек профиля обрабатывает 100 запросов — одной реплики достаточно. Это экономит ресурсы при неравномерной нагрузке.

Межсервисная коммуникация добавляет латентность. Каждый внутренний HTTP или gRPC вызов — это 1–10 мс сетевой задержки. Если обработка одного запроса требует цепочки из 5 сервисов — это 5–50 мс дополнительной задержки. Для большинства приложений это приемлемо, но для high-frequency trading или real-time gaming — критично.

Промежуточный вариант: модульный монолит

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

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

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

Решающие вопросы

Размер команды — определяющий фактор. Команде до 10 человек микросервисы создадут больше проблем, чем решат. При 30+ разработчиках — координация внутри монолита становится узким местом, и микросервисы начинают оправдывать себя.

Зрелость DevOps-культуры — второй фактор. Если в компании нет CI/CD, мониторинга и автоматизации — микросервисы превратятся в хаос. Сначала постройте инфраструктурный фундамент, потом декомпозируйте приложение.

Природа продукта — третий фактор. Если разные части продукта развиваются с разной скоростью и разными командами — микросервисы помогают. Если продукт компактный и команда единая — монолит эффективнее.

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