Vladimir.Sidorov
New member
За последние десять лет я успел построить и пару больших монолитов, и распределённую систему из трёх десятков сервисов, и честно скажу: спор про архитектуру давно перестал быть техническим. Он стал финансовым и организационным. В 2025 году вопрос звучит не «что моднее», а «сколько людей у меня в команде, сколько денег я готов жечь на облако и как часто бизнес меняет требования». Если ответить на эти три вопроса честно, выбор делается почти автоматически.
Начну с монолита, потому что его незаслуженно записали в устаревшее. Я вёл продукт на монолите четыре года: один репозиторий, одна база, один деплой. Мы выпускали релизы каждый день, а инфраструктура обходилась дешевле, чем кофе для команды. Рефакторинг был больно, зато вся система помещалась в голову целиком. Для стартапа, для внутренней системы, для продукта с командой до десяти разработчиков монолит в 2025 году остаётся самым разумным выбором. Главное — держать модульность внутри кода, а не в сетевых вызовах.
Микросервисы я тоже проходил, и не по хайпу, а по необходимости. У нас было три команды, которые физически не могли работать в одном репозитории: постоянные конфликты, блокирующие релизы, разные циклы изменений. Мы вынесли платежи, уведомления и аналитику в отдельные сервисы, и это сразу дало то, за что платят: независимые деплои и понятные границы ответственности. Но цена оказалась высокой. Логи, трассировка, очереди, service mesh, дежурства — мы наняли двух инженеров, которые занимались только платформой. Это не overhead, это обязательные расходы.
Про инфраструктуру хочу сказать отдельно, потому что тут чаще всего и переплачивают. Один сервис в контейнере — это не только CPU и память, это ещё база, кэш, брокер, балансировщик, мониторинг и хранилище логов. Умножаем на тридцать сервисов и получаем счёт, который растёт быстрее выручки. Я сам однажды обнаружил, что половину бюджета съедают среды разработки и стенды для каждого сервиса. Мы схлопнули их до общей среды, и экономия оказалась сопоставима с зарплатой инженера.
В 2025 году я всё чаще советую промежуточный путь — модульный монолит с возможностью вынести часть наружу, когда появится реальная причина. Плюс современные инструменты сильно упростили жизнь: контейнеры стали скучными и надёжными, оркестрация доступна небольшим командам, а управляемые сервисы убрали большую часть боли с базами и очередями. Но магия исчезла не полностью: распределённая система по-прежнему требует зрелости команды, а не только бюджета.
Вот мой практический чек-лист. Выбирайте монолит, если у вас одна команда, домен ещё меняется и вам важна скорость гипотез. Идите в микросервисы, если есть несколько автономных команд, чёткие границы доменов и человек, который будет отвечать за платформу и наблюдаемость. И никогда не начинайте с микросервисов только потому, что так написано в вакансиях и конференциях — это самый дорогой способ сделать резюме, но не продукт.
Отдельно скажу про самое частое заблуждение. Люди думают, что микросервисы решают проблему плохого кода. Не решают. Плохой код просто начинает общаться по сети, добавляя к старым проблемам новые: таймауты, частичные сбои, дублирование данных и согласованность. Если модуль внутри монолита превратился в кашу, то сервис из него получится такая же каша, только с брокером сообщений и счётом за трафик.
А теперь вопрос к вам, форумчане: что вы выбрали для своего последнего проекта — монолит, микросервисы или что-то посередине, и что стало решающим аргументом? Расскажите свою историю, мне правда интересно, где сейчас проходит эта граница у коллег.
Начну с монолита, потому что его незаслуженно записали в устаревшее. Я вёл продукт на монолите четыре года: один репозиторий, одна база, один деплой. Мы выпускали релизы каждый день, а инфраструктура обходилась дешевле, чем кофе для команды. Рефакторинг был больно, зато вся система помещалась в голову целиком. Для стартапа, для внутренней системы, для продукта с командой до десяти разработчиков монолит в 2025 году остаётся самым разумным выбором. Главное — держать модульность внутри кода, а не в сетевых вызовах.
Микросервисы я тоже проходил, и не по хайпу, а по необходимости. У нас было три команды, которые физически не могли работать в одном репозитории: постоянные конфликты, блокирующие релизы, разные циклы изменений. Мы вынесли платежи, уведомления и аналитику в отдельные сервисы, и это сразу дало то, за что платят: независимые деплои и понятные границы ответственности. Но цена оказалась высокой. Логи, трассировка, очереди, service mesh, дежурства — мы наняли двух инженеров, которые занимались только платформой. Это не overhead, это обязательные расходы.
Про инфраструктуру хочу сказать отдельно, потому что тут чаще всего и переплачивают. Один сервис в контейнере — это не только CPU и память, это ещё база, кэш, брокер, балансировщик, мониторинг и хранилище логов. Умножаем на тридцать сервисов и получаем счёт, который растёт быстрее выручки. Я сам однажды обнаружил, что половину бюджета съедают среды разработки и стенды для каждого сервиса. Мы схлопнули их до общей среды, и экономия оказалась сопоставима с зарплатой инженера.
В 2025 году я всё чаще советую промежуточный путь — модульный монолит с возможностью вынести часть наружу, когда появится реальная причина. Плюс современные инструменты сильно упростили жизнь: контейнеры стали скучными и надёжными, оркестрация доступна небольшим командам, а управляемые сервисы убрали большую часть боли с базами и очередями. Но магия исчезла не полностью: распределённая система по-прежнему требует зрелости команды, а не только бюджета.
Вот мой практический чек-лист. Выбирайте монолит, если у вас одна команда, домен ещё меняется и вам важна скорость гипотез. Идите в микросервисы, если есть несколько автономных команд, чёткие границы доменов и человек, который будет отвечать за платформу и наблюдаемость. И никогда не начинайте с микросервисов только потому, что так написано в вакансиях и конференциях — это самый дорогой способ сделать резюме, но не продукт.
Отдельно скажу про самое частое заблуждение. Люди думают, что микросервисы решают проблему плохого кода. Не решают. Плохой код просто начинает общаться по сети, добавляя к старым проблемам новые: таймауты, частичные сбои, дублирование данных и согласованность. Если модуль внутри монолита превратился в кашу, то сервис из него получится такая же каша, только с брокером сообщений и счётом за трафик.
А теперь вопрос к вам, форумчане: что вы выбрали для своего последнего проекта — монолит, микросервисы или что-то посередине, и что стало решающим аргументом? Расскажите свою историю, мне правда интересно, где сейчас проходит эта граница у коллег.