Слово «монолит» в IT часто звучит негативно. Большая система, общий релиз, один код, много зависимостей — кажется, что следующий логичный шаг всегда микросервисы.
Но монолит сам по себе не проблема. Проблемой он становится тогда, когда его устройство начинает мешать бизнесу менять продукт.
Что такое монолит
В простом виде это приложение, основные части которого развиваются и разворачиваются вместе. Пользователи, каталог, заказы, платежи и другие функции могут находиться в одной системе и использовать общую инфраструктуру.
Это ограничивает независимость частей системы, но одновременно убирает множество проблем распределённой архитектуры.
Какую проблему мы решаем
В начале продукта главная задача обычно не в том, чтобы независимо масштабировать десятки сервисов. Нужно быстрее проверить идеи, выпускать изменения и не тратить значительную часть команды на инфраструктуру.
Монолит даёт простую модель: меньше компонентов, меньше сетевых взаимодействий, один процесс доставки изменений и меньше мест, где система может сломаться только из-за сложности взаимодействия между её частями.
Что получает бизнес
Главная выгода — скорость при относительно низкой стоимости архитектуры.
Небольшая команда может развивать продукт без отдельной платформенной функции, сложной наблюдаемости и большого количества инфраструктурных компонентов. Деньги и время идут в продукт, а не в обслуживание распределённости.
Это особенно важно там, где продукт, рынок или бизнес-модель ещё меняются. В такой ситуации способность быстро переделывать систему часто ценнее, чем возможность независимо развернуть отдельный сервис.
Монолит также упрощает прогнозирование расходов: меньше инфраструктуры, меньше операционных зависимостей и обычно меньше специальных компетенций, которые необходимо поддерживать постоянно.
Что получает команда
Разработчику проще запустить систему локально, проследить бизнес-процесс от начала до конца и изменить несколько связанных частей в одной кодовой базе.
Транзакции и согласованность данных обычно проще. Не нужно превращать обычную операцию в цепочку сетевых вызовов и потом разбираться, что делать, если третий из пяти шагов не ответил.
Но простота быстро исчезает, если внутри монолита нет границ. Когда любой модуль знает всё обо всех остальных, одна кодовая база превращается не в преимущество, а в источник постоянного риска.
Что получает клиент
Клиенту всё равно, сколько приложений работает внутри компании.
Если простая архитектура позволяет быстрее исправлять ошибки, выпускать функции и не создавать сбои на стыках десятков сервисов, клиент выигрывает.
И наоборот: сложная архитектура не создаёт клиентской ценности сама по себе.
Чем мы за это платим
Цена монолита появляется с ростом.
Независимые команды могут начать мешать друг другу. Общий релиз становится тяжелее. Нельзя легко масштабировать только одну горячую часть системы. Ошибка в одном процессе потенциально затрагивает всё приложение.
Есть и более опасная цена — накопление внутренних зависимостей. Если границы не поддерживать годами, каждое изменение начинает затрагивать всё больше системы.
Когда монолит перестаёт быть выгодным
- Несколько команд регулярно блокируют релизы друг друга.
- Отдельные части системы требуют принципиально разного масштабирования.
- Общий релиз заметно замедляет выход продуктовых изменений.
- Сбой одной части слишком часто влияет на весь продукт.
- Стоимость изменения растёт из-за связности системы, а не из-за сложности самой задачи.
Что стоит спросить перед решением
- Какая конкретная проблема монолита уже стоит бизнесу денег или скорости?
- Можно ли решить её хорошими модульными границами?
- Нужны ли отдельным командам действительно независимые релизы?
- Будет ли новая архитектура дешевле текущей проблемы?
В итоге
Монолит — не признак технической незрелости. Это один из архитектурных вариантов со своей областью применения.
Если простая система позволяет бизнесу двигаться быстро и не создаёт реальных ограничений, усложнять её только ради модной архитектуры — плохая инвестиция.