ArtyomBelov
New member
Сколько раз я слышал этот спор на кухнях айтишных офисов и в рабочих чатах: монолит — это легаси, микросервисы — это будущее. Или наоборот: микросервисы — это распределённый ад, а монолит — единственный путь для вменяемого человека. За десять лет я успел посидеть по обе стороны баррикад, и сейчас, в 2025 году, могу сказать одно: спорщики обычно защищают не архитектуру, а свою зарплату, свою команду и своё эго. Давайте разберёмся по-честному, без религии.
Мой первый большой проект был классическим монолитом. Четыре разработчика, один репозиторий, один сервер, база данных, деплой — скриптом через ssh. И знаете что? Мы выпускали фичи быстрее, чем сейчас выпускаю я с двумя десятками сервисов и фулл-тайм платформенной командой. Локально всё поднималось одной командой, отладка была линейной, а новый человек в команде выходил на первую задачу за день. Монолит не был тормозом — тормозом была наша неаккуратность в коде и отсутствие тестов.
Потом был период распила. Мода, инвесторы, желание масштабироваться и, честно говоря, амбиции архитектора. Мы разбили продукт на тридцать с лишним сервисов, подняли Kubernetes, добавили брокер сообщений, распределённый трейсинг, сервис-меш. Итог первого года: время выхода фичи выросло в разы, половина инцидентов — это сетевые таймауты и расхождения данных между сервисами, а на инфраструктуру уходила заметная часть бюджета. Мы получили не независимые сервисы, а распределённый монолит с ещё более запутанными связями.
При этом я не буду врать в другую сторону: были задачи, где микросервисы реально спасли. Когда над продуктом работают пять команд в разных часовых поясах, когда у поиска и биллинга кардинально разный профиль нагрузки, когда надо выкатить новую модель на Python рядом с ядром на Go — тут разделение даёт настоящее преимущество. Но обратите внимание: во всех этих случаях причина была организационной или технологической, а не идеологической. Микросервисы решают проблемы людей и масштаба, а не проблемы плохого кода.
Сейчас, в 2025 году, картина стала ещё интереснее. С одной стороны, платформенная инженерия подорожала: облако, наблюдаемость, безопасность, стоимость специалистов. С другой — модульный монолит вернулся в повестку не как компромисс, а как осознанный выбор. Мы научились строить монолит с чёткими границами модулей, а ИИ-ассистенты наконец начали уверенно ориентироваться в больших кодовых базах, что снимает главный аргумент про сложность навигации. Плюс многие команды устали платить за распределённость там, где она не нужна.
Мои рекомендации читателям звучат так. Начинайте с монолита — модульного, с явными границами и тестами, если у вас одна команда и продукт ещё ищет свою форму. Выделяйте сервис только тогда, когда у вас есть конкретная боль: независимый релизный цикл для другой команды, разный профиль нагрузки или принципиально иной стек. Инвестируйте в наблюдаемость и CI раньше, чем в оркестратор. И главное — не принимайте архитектурное решение один раз навсегда: границы можно и нужно двигать по мере роста.
Архитектура — это не религия и не знамя, это инструмент под конкретную команду, продукт и бюджет на конкретный момент времени. Если ваша система приносит пользу пользователям и не мешает вам спать по ночам, вы, скорее всего, выбрали правильно, что бы про это ни говорили в твиттере. Так что расскажите: а какую архитектуру вы выбрали и что стало главным аргументом — технологии, команда или просто здравый смысл и усталость от хайпа?
Мой первый большой проект был классическим монолитом. Четыре разработчика, один репозиторий, один сервер, база данных, деплой — скриптом через ssh. И знаете что? Мы выпускали фичи быстрее, чем сейчас выпускаю я с двумя десятками сервисов и фулл-тайм платформенной командой. Локально всё поднималось одной командой, отладка была линейной, а новый человек в команде выходил на первую задачу за день. Монолит не был тормозом — тормозом была наша неаккуратность в коде и отсутствие тестов.
Потом был период распила. Мода, инвесторы, желание масштабироваться и, честно говоря, амбиции архитектора. Мы разбили продукт на тридцать с лишним сервисов, подняли Kubernetes, добавили брокер сообщений, распределённый трейсинг, сервис-меш. Итог первого года: время выхода фичи выросло в разы, половина инцидентов — это сетевые таймауты и расхождения данных между сервисами, а на инфраструктуру уходила заметная часть бюджета. Мы получили не независимые сервисы, а распределённый монолит с ещё более запутанными связями.
При этом я не буду врать в другую сторону: были задачи, где микросервисы реально спасли. Когда над продуктом работают пять команд в разных часовых поясах, когда у поиска и биллинга кардинально разный профиль нагрузки, когда надо выкатить новую модель на Python рядом с ядром на Go — тут разделение даёт настоящее преимущество. Но обратите внимание: во всех этих случаях причина была организационной или технологической, а не идеологической. Микросервисы решают проблемы людей и масштаба, а не проблемы плохого кода.
Сейчас, в 2025 году, картина стала ещё интереснее. С одной стороны, платформенная инженерия подорожала: облако, наблюдаемость, безопасность, стоимость специалистов. С другой — модульный монолит вернулся в повестку не как компромисс, а как осознанный выбор. Мы научились строить монолит с чёткими границами модулей, а ИИ-ассистенты наконец начали уверенно ориентироваться в больших кодовых базах, что снимает главный аргумент про сложность навигации. Плюс многие команды устали платить за распределённость там, где она не нужна.
Мои рекомендации читателям звучат так. Начинайте с монолита — модульного, с явными границами и тестами, если у вас одна команда и продукт ещё ищет свою форму. Выделяйте сервис только тогда, когда у вас есть конкретная боль: независимый релизный цикл для другой команды, разный профиль нагрузки или принципиально иной стек. Инвестируйте в наблюдаемость и CI раньше, чем в оркестратор. И главное — не принимайте архитектурное решение один раз навсегда: границы можно и нужно двигать по мере роста.
Архитектура — это не религия и не знамя, это инструмент под конкретную команду, продукт и бюджет на конкретный момент времени. Если ваша система приносит пользу пользователям и не мешает вам спать по ночам, вы, скорее всего, выбрали правильно, что бы про это ни говорили в твиттере. Так что расскажите: а какую архитектуру вы выбрали и что стало главным аргументом — технологии, команда или просто здравый смысл и усталость от хайпа?