Начните с модульного монолита
Одна кодовая база, один деплой — но с чёткими внутренними границами между модулями. Это самый быстрый способ строить сейчас, и он сохраняет возможность выделить сервис позже, когда вы реально поймёте, где проходят швы.
Выбирайте это, когда
- Одна команда или ранний продукт, который ещё меняет форму
- Всё масштабируется вместе, а ops — маленькая команда
- Хотите двигаться быстро и сохранить варианты открытыми
Компромиссы
- Нужна дисциплина, чтобы границы модулей не размывались
- Всё деплоится вместе — одно плохое изменение держит остальное
- Очень разные потребности в масштабировании со временем заставят выделить часть
Оставьте монолит, выделите один сервис
Основное оставьте монолитом и вынесите только ту часть, у которой есть конкретная причина быть отдельной, — кусок, который масштабируется иначе или которым владеет отдельная команда. Один шов, а не двадцать.
Выбирайте это, когда
- У одной части сильно другая нагрузка или требования к железу
- Или конкретной команде нужно владеть и деплоить одну область отдельно
- И у вас есть ops-мускул, чтобы тянуть больше одного сервиса
Компромиссы
- Теперь есть сетевая граница, которую нужно спроектировать, версионировать и мониторить
- Соблазн — продолжать дробить; держитесь, пока нет новой причины
Идите в микросервисы
Несколько команд, устоявшийся домен и настоящий платформенный мускул — это та ситуация, под которую микросервисы и создавались. Дробите по границам команд и доменов, чтобы каждая команда релизила по своему графику.
Выбирайте это, когда
- Несколько команд толкаются в одном пайплайне
- Стабильные, понятные границы домена, по которым можно дробить
- Платформенная команда и зрелые CI/CD, мониторинг и дежурства
Компромиссы
- Большая операционная цена: сеть, деплои, трейсинг, обработка отказов
- Распределённые системы сложны — частичные сбои и согласованность данных становятся ежедневной работой
- Неправильные границы дорого двигать, когда сервисы уже живут