Монолит против микросервисов

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

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

Главная идея

Микросервисы решают проблемы команды и операций, а не код. Начинать стоит с монолита и дробить по реальным болям.

Как это выглядит на практике

Стартап пишет монолит — все деплои и команды в одном репозитории.
Команда растёт до 50 человек, начинаются конфликты в одном кодовом базе.
Выделяют первый сервис — биллинг — с собственной БД и API.
Постепенно появляются другие сервисы по границам бизнес-домена.

Что происходит под капотом

Monolith first: начинайте с монолита, дробите по фактическим точкам трения.
Service ownership: один сервис — одна команда; иначе появляется 'distributed monolith'.
Database per service: общая БД превращает микросервисы в распределённый монолит.
Контракты между сервисами должны быть стабильными и версионироваться.

Типичные ошибки и заблуждения

Ошибка: микросервисы быстрее монолита. На малых нагрузках сетевой оверхед делает их медленнее.
Ошибка: больше сервисов = лучше. После определённого числа сервисов сложность операций становится непосильной.
Ошибка: микросервисы решают плохую архитектуру. Плохой код станет распределённым плохим кодом.
Ошибка: общая БД между сервисами — это нормально. Это антипаттерн distributed monolith.

Ключевые выводы

Monolith first — почти всегда правильный старт.
Дробите по бизнес-границам, а не по техническим.
Каждый сервис должен иметь свою БД.
Микросервисы — про команды и операции, не про код.

Термины урока

Monolith: единое приложение с общим деплоем и БД.

Microservice: малый сервис, развиваемый и деплоящийся независимо.

Distributed monolith: микросервисы с общей БД или жёсткими связями.

Bounded context: чётко очерченная область бизнес-логики (DDD).

Связь с работой backend-разработчика

Решение о переходе на микросервисы — техническое и организационное одновременно. Backend-разработчик должен уметь оценить и то, и другое.

Мини-разбор реальной ситуации

Команда из 5 человек разделила приложение на 12 микросервисов 'для будущего масштабирования'. Деплой одной фичи теперь требовал координации 4 сервисов. Через год вернулись к модульному монолиту.

Что запомнить

Сначала монолит, потом микросервисы.
Дробите по болям, а не по моде.
Каждому сервису — свою БД.

Итог

Микросервисы — это инструмент решения конкретных проблем масштаба, а не цель сама по себе.