Когда делить монолит на микросервисы - и когда не стоит
Практический взгляд на то, в какой момент декомпозиция архитектуры оправдана, а когда она создаёт больше проблем, чем решает.
Микросервисная архитектура стала одним из самых обсуждаемых подходов в последние несколько лет. Команды, которые слышали об успехах Netflix или Amazon, начинают проектировать системы в том же духе - независимые сервисы, отдельные деплои, изолированные базы данных.
Я понимаю привлекательность этого образа. Но вопрос не в том, правильны ли микросервисы в принципе. Вопрос в том, правильны ли они для вашей компании прямо сейчас.
Что микросервисы на самом деле дают
Основные преимущества реальны: независимое масштабирование отдельных частей системы, изолированные отказы, возможность для разных команд работать и деплоить независимо, свобода выбора технологии на уровне отдельного сервиса.
Всё это имеет цену. Распределённые системы сложнее монолитных по определению. Нужны решения для сервисного обнаружения, трассировки запросов, централизованного логирования, оркестрации развёртываний. Отладка становится труднее - запрос проходит через несколько сервисов, и найти, где именно что-то сломалось, требует инструментов и дисциплины.
Когда монолит - это не стыдно
Монолит, написанный аккуратно - с хорошей модульной структурой внутри - часто лучше подходит для компании, которая ещё формирует продукт. Когда бизнес-логика меняется часто, когда границы доменов ещё не устоялись, монолит позволяет быстро рефакторить и переосмыслять структуру.
Переход к микросервисам до того, как вы понимаете реальные границы доменов, это заморозить неверное деление. Вы получите сервисы, которые сильно связаны между собой, или сервисы настолько мелкие, что каждая фича требует изменений в пяти репозиториях.
Стартапы и продукты на ранних стадиях обычно не нуждаются в микросервисах. У них нет нескольких команд, которые мешают друг другу. У них нет компонентов с принципиально разными требованиями к масштабированию. Микросервисы в этом контексте - это инфраструктурная нагрузка без соответствующей отдачи.
Сигналы, что деление стало нужным
Есть несколько ситуаций, когда разговор о декомпозиции начинает иметь смысл:
- несколько команд регулярно конфликтуют при работе в одном репозитории или при деплое;
- один компонент системы требует масштабирования принципиально иначе, чем остальные;
- скорость деплоя стала значимой проблемой из-за размера и связности кодовой базы;
- изолированный отказ одного модуля должен не влиять на остальную систему.
Если ни одно из этих условий не выполняется - ускорение, которое даст декомпозиция, скорее всего не компенсирует сложность, которую она добавит.
Как подойти к этому решению
Несколько вопросов, которые помогают сформулировать позицию:
- Есть ли у нас несколько команд, которые сейчас замедляют друг друга из-за общей кодовой базы?
- Понимаем ли мы реальные границы бизнес-доменов достаточно хорошо, чтобы провести правильные разрезы?
- Есть ли у нас эксплуатационная зрелость для поддержки распределённой системы - мониторинг, трассировка, оркестрация?
- Есть ли конкретный компонент с аномальными требованиями к нагрузке, который вынуждает масштабировать всё остальное?
- Готовы ли мы к тому, что переход займёт не месяц, а год, и потребует параллельной поддержки двух систем?
Если ответы неуверенные - вероятно, сейчас не время. Хороший монолит с чёткими модульными границами - это честный выбор, а не техдолг.