Модульный монолит против микросервисов: когда распил окупается

Фраза «переведём в микросервисы и в облако» часто звучит как стратегия, а на деле увеличивает счёт за сопровождение раньше, чем ускоряет поставку. Алексей Меркулов (Fobscraft) считает распил как инвестицию: затраты сейчас, затраты каждый месяц, эффект в скорости команд и радиусе аварии. Ниже — когда достаточно модулей в одном деплое и когда отдельный сервис уже окупается. Проектирование границ — через услуги Fobscraft.

Сцена, с которой начинается спор

Обратите внимание на разговор на совещании. Продукт тормозит релизы. Кто-то показывает схему из пятнадцати квадратиков. Кто-то обещает, что «как у больших компаний» станет проще нанимать и масштабировать.

Через полгода картина другая: больше репозиториев, больше пайплайнов, дольше искать, где упало. Фичи всё ещё ждут друг друга, потому что данные и люди остались общими.

Почему обещание разошлось с жизнью? Потому что сеть сервисов чинит только те боли, которые уже есть: разные владельцы, разные циклы, разный счёт за железо. Если болей нет, вы покупаете сложность заранее.

Что даёт модульный монолит

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

Такой контур часто выглядит «слишком простым» на слайде. На практике он позволяет менять продукт быстро: нет сетевой задержки между своими же модулями, нет двойного логирования на каждый чих.

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

Закрепим. Документный портал с анализаторами и AI-командой — много смысловых областей, один деплой, отдельные пространства API. Это как раз случай, где границы важны, а лишние сетевые прыжки ещё не окупаются.

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

Теперь изменим условия. Появляется вторая команда с другим ритмом релизов. Или один контур жрёт процессор так, что вместе с ним дорожает оплата и админка. Или правила работы с данными требуют физической изоляции.

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

Принцип: распил окупается, когда платите за независимость, которая уже нужна. Иначе вы платите за независимость, которой пока некому пользоваться.

Практичный порядок работ

Сначала зафиксируйте модули и запреты пересечения границ. Затем вынесите в очереди то, что и так асинхронно: импорт, длинные AI-задачи, тяжёлые отчёты. Наружу выносите только то, что реально масштабируется отдельно или принадлежит другой команде. И каждый раз считайте месяц инфраструктуры до и после.

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

Что вы теперь можете объяснить

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