Монолит или сервисы: как принять решение без инженерного фона
Практическое объяснение для собственников и директоров: когда дробить архитектуру на сервисы оправданно, а когда это лишние затраты.
Если вы владелец или CEO компании с работающим продуктом, рано или поздно технический директор или подрядчик приходит с предложением: "Нам надо переходить на микросервисы". Звучит как что-то неизбежное. Иногда так и есть. Чаще - нет.
Я видел достаточно таких переходов, чтобы сказать: решение принимается не из технических соображений первым делом. Оно принимается из организационных и операционных. И именно поэтому его стоит понять на уровне бизнеса, а не только на уровне кода.
Что такое монолит на самом деле
Монолит - это когда всё приложение развёртывается как одна единица. Изменение в любой части требует пересборки и перезапуска всего. Команды работают в одной кодовой базе.
У этого есть реальные плюсы. Проще поддерживать единую схему данных. Проще отлаживать - всё в одном месте. Меньше инфраструктурной сложности. Для большинства продуктов на ранней и средней стадии монолит - это правильный выбор.
Проблемы начинаются, когда команда вырастает настолько, что люди постоянно наступают друг другу на ноги в одной кодовой базе. Или когда разным частям продукта нужно масштабироваться принципиально по-разному. Или когда каждое небольшое изменение требует полного цикла выкатки и тестирования.
Что такое микросервисы на самом деле
Микросервисы - это когда приложение разбито на независимые компоненты, каждый из которых разворачивается и масштабируется отдельно. Разные команды могут работать и выпускать независимо.
Звучит привлекательно. Но за это платят: появляется сетевое взаимодействие между сервисами, которое может ломаться. Появляются отдельные базы данных, которые надо синхронизировать. Появляется инфраструктура оркестрации. Каждый сервис нужно мониторить отдельно. Простая задача "посмотреть что пошло не так" превращается в детективную историю по нескольким логам.
Микросервисы решают проблемы масштаба команды и масштаба нагрузки. Если у вас нет ни той, ни другой проблемы - переход принесёт сложность, но не ценность.
Какой вопрос задать своей команде
Когда технический директор предлагает переход, правильный вопрос не "это современно?" и не "так делают все?". Правильный вопрос - это набор конкретных вещей:
- Какую конкретную проблему мы сейчас решаем - медленные релизы, конфликты команд, проблемы с нагрузкой?
- Сколько людей работает в кодовой базе одновременно?
- Есть ли у нас опыт управления распределёнными системами в команде?
- Какова оценка трудозатрат на переход и кто будет за это отвечать?
- Что произойдёт с текущими задачами продукта во время перехода?
Если на первый вопрос нет конкретного ответа - разговор преждевременный.
Признаки, что переход оправдан
Есть несколько сигналов, после которых разговор о переходе становится предметным:
- Команда разработки выросла до 15-20 человек, работающих в одной кодовой базе, и релизный цикл сломан из-за постоянных конфликтов.
- Разные части системы имеют принципиально разные требования к нагрузке и масштабированию.
- Конкретный модуль стал узким местом и его невозможно масштабировать независимо от остального.
- Регуляторные или безопасностные требования требуют жёсткой изоляции отдельных компонент.
Признаки, что переход преждевременен
Признаки другой стороны:
- Команда меньше 10 человек в разработке.
- Продукт ещё активно ищет форму - быстро меняется функциональность.
- Нет выделенного инфраструктурного инженера или SRE, который будет управлять всем этим хозяйством.
- Переход предлагается потому что "так принято" или "хочется попробовать", а не под конкретную боль.
Монолит, написанный с дисциплиной, работает годами и обслуживает миллионы пользователей. Микросервисы, внедрённые без зрелой инфраструктурной команды, превращаются в распределённый монолит с дополнительной болью.
Решение об архитектуре - это в первую очередь решение об организации команды. Именно с этого стоит начинать разговор.