Alex_Wilson
New member
Спор про микросервисы и монолит идёт уже лет десять, и каждый год я надеюсь, что он наконец утихнет. Не утихает. За последние семь лет я успел побывать в роли разработчика в небольшой команде на монолите, тимлида на проекте, который распиливали на сервисы, и консультанта, который разгребал последствия обеих крайностей. Поэтому пишу не по книжкам, а по своим синякам и шишкам.
Сначала честная история. У меня был проект — обычная внутренняя система для среднего бизнеса, пять разработчиков, пара интеграций и база данных, которая всех устраивала. Мы держали монолит, разбитый на модули по предметным областям, с честными границами и запретом лезть в чужие таблицы. И знаете что? За три года мы ни разу не пожалели. Деплой занимал пятнадцать минут, новый человек в команде разбирался за неделю, а когда понадобилось срочно починить отчётность, мы это сделали в тот же вечер, а не собирали консилиум из четырёх команд.
А вот вторую историю вспоминаю с содроганием. Там была модная архитектура: десятки сервисов, брокер сообщений, оркестратор, отдельные базы у каждого. И при этом команда осталась та же — примерно те же десять человек, только теперь они назывались платформенной группой. В итоге половина времени уходила не на продукт, а на инфраструктуру: локально поднять всё вместе было почти невозможно, интеграционные тесты падали от чужого релиза, а простой запрос пользователя приходилось ловить по логам пяти сервисов. Мы получили распределённый монолит — худшее из двух миров, где сложность микросервисов сочеталась со связностью обычной большой кодовой базы.
Теперь главное, что я вынес из этих двух опытов. Выбор между монолитом и микросервисами — это почти никогда не техническое решение о коде. Это решение о людях и процессах. Смотреть надо на три вещи: сколько у вас команд и есть ли у них реальная автономия, насколько сложная и разнородная предметная область, и есть ли у вас культура эксплуатации — мониторинг, логи, алерты, дежурства, автоматизация выката. Если хотя бы по одному пункту зияет дыра, микросервисы эту дыру не закроют, а раздуют до размеров бюджета.
Поэтому мой прагматичный дефолт на 2025 год звучит скучно: модульный монолит. Соблюдайте границы внутри, не давайте модулям ползти друг в друга, держите один деплой, но проектируйте так, чтобы любой кусок можно было вынести наружу без археологических раскопок. Я видел, как такая дисциплина позволяла потом выделять сервисы по одному, без героизма и ночных деплоев, ровно тогда, когда появлялась настоящая боль, а не модное желание.
Микросервисы действительно оправданы, и тут я не буду строить из себя борца с ними. Они выигрывают, когда команд много и они мешают друг другу в одном репозитории, когда разные части системы требуют разных технологий или кратно разной нагрузки, когда нужна изоляция сбоев и независимый релизный цикл критичен для бизнеса. Ещё один честный сценарий: когда продукт реально большой и живёт годами, а стоимость владения инфраструктурой у вас давно посчитана и принята осознанно, а не спрятана в энтузиазме двух архитекторов.
Что бы я посоветовал читателю, который сейчас стоит перед этим выбором. Первое: измерьте, сколько времени команда тратит на сам продукт, а сколько на инфраструктуру — цифры часто шокируют. Второе: не проектируйте архитектуру под гипотетический рост, которого может и не быть. Третье: если очень хочется микросервисов, начните с одного выделенного сервиса на периферии и посмотрите, как команда живёт с ним месяц. И четвёртое: границы важнее формата. Хорошо нарезанный монолит лучше плохо нарезанных сервисов, и это правило я готов защищать на любом форуме.
В сухом остатке: нет универсально правильного ответа, есть ответ, подходящий вашей команде прямо сейчас. Начинайте с простого, усложняйте по факту боли, а не по факту статьи в интернете. Монолит не признак отсталости, микросервисы не признак зрелости — признаком зрелости я считаю способность называть свои ограничения вслух. А теперь вопрос к вам, форумчане: с чем вы работали в этом году и что оказалось самым неожиданным в вашем выборе — приятным или не очень?
Сначала честная история. У меня был проект — обычная внутренняя система для среднего бизнеса, пять разработчиков, пара интеграций и база данных, которая всех устраивала. Мы держали монолит, разбитый на модули по предметным областям, с честными границами и запретом лезть в чужие таблицы. И знаете что? За три года мы ни разу не пожалели. Деплой занимал пятнадцать минут, новый человек в команде разбирался за неделю, а когда понадобилось срочно починить отчётность, мы это сделали в тот же вечер, а не собирали консилиум из четырёх команд.
А вот вторую историю вспоминаю с содроганием. Там была модная архитектура: десятки сервисов, брокер сообщений, оркестратор, отдельные базы у каждого. И при этом команда осталась та же — примерно те же десять человек, только теперь они назывались платформенной группой. В итоге половина времени уходила не на продукт, а на инфраструктуру: локально поднять всё вместе было почти невозможно, интеграционные тесты падали от чужого релиза, а простой запрос пользователя приходилось ловить по логам пяти сервисов. Мы получили распределённый монолит — худшее из двух миров, где сложность микросервисов сочеталась со связностью обычной большой кодовой базы.
Теперь главное, что я вынес из этих двух опытов. Выбор между монолитом и микросервисами — это почти никогда не техническое решение о коде. Это решение о людях и процессах. Смотреть надо на три вещи: сколько у вас команд и есть ли у них реальная автономия, насколько сложная и разнородная предметная область, и есть ли у вас культура эксплуатации — мониторинг, логи, алерты, дежурства, автоматизация выката. Если хотя бы по одному пункту зияет дыра, микросервисы эту дыру не закроют, а раздуют до размеров бюджета.
Поэтому мой прагматичный дефолт на 2025 год звучит скучно: модульный монолит. Соблюдайте границы внутри, не давайте модулям ползти друг в друга, держите один деплой, но проектируйте так, чтобы любой кусок можно было вынести наружу без археологических раскопок. Я видел, как такая дисциплина позволяла потом выделять сервисы по одному, без героизма и ночных деплоев, ровно тогда, когда появлялась настоящая боль, а не модное желание.
Микросервисы действительно оправданы, и тут я не буду строить из себя борца с ними. Они выигрывают, когда команд много и они мешают друг другу в одном репозитории, когда разные части системы требуют разных технологий или кратно разной нагрузки, когда нужна изоляция сбоев и независимый релизный цикл критичен для бизнеса. Ещё один честный сценарий: когда продукт реально большой и живёт годами, а стоимость владения инфраструктурой у вас давно посчитана и принята осознанно, а не спрятана в энтузиазме двух архитекторов.
Что бы я посоветовал читателю, который сейчас стоит перед этим выбором. Первое: измерьте, сколько времени команда тратит на сам продукт, а сколько на инфраструктуру — цифры часто шокируют. Второе: не проектируйте архитектуру под гипотетический рост, которого может и не быть. Третье: если очень хочется микросервисов, начните с одного выделенного сервиса на периферии и посмотрите, как команда живёт с ним месяц. И четвёртое: границы важнее формата. Хорошо нарезанный монолит лучше плохо нарезанных сервисов, и это правило я готов защищать на любом форуме.
В сухом остатке: нет универсально правильного ответа, есть ответ, подходящий вашей команде прямо сейчас. Начинайте с простого, усложняйте по факту боли, а не по факту статьи в интернете. Монолит не признак отсталости, микросервисы не признак зрелости — признаком зрелости я считаю способность называть свои ограничения вслух. А теперь вопрос к вам, форумчане: с чем вы работали в этом году и что оказалось самым неожиданным в вашем выборе — приятным или не очень?