Alex.Popov
New member
За последние годы я успел побывать и в роли разработчика, который с энтузиазмом резал монолит на сервисы, и в роли того, кто потом полгода разгребал последствия этого энтузиазма. Поэтому тема «микросервисы против монолита» для меня давно не абстрактная дискуссия с конференций, а конкретные бессонные ночи и сожжённые спринты. И главный вывод, к которому я пришёл к 2025 году, звучит скучно: архитектура сама по себе скорость не даёт. Скорость даёт соответствие архитектуры размеру команды, зрелости процессов и стабильности домена.
Первый мой опыт был как раз с монолитом. Продукт, четыре разработчика, одна кодовая база, один пайплайн, деплой за пятнадцать минут. Новую фичу мы выкатывали за пару дней, включая код, тесты и релиз, а отладка сквозного сценария занимала один прогон в IDE. Мы тогда шутили, что монолит — это наш скрытый конкурентный бонус: пока конкуренты согласовывали контракты между сервисами, мы просто меняли функцию и шли дальше.
Второй опыт был уже в компании крупнее. Сорок с лишним человек, три продуктовых направления, и решение «сделать как у взрослых»: три десятка сервисов, брокер сообщений, service mesh, отдельные репозитории у каждой команды. Через год мы получили ровно обратное тому, зачем всё это затевали. Одна пользовательская фича требовала изменений в пяти сервисах, локально поднять весь зоопарк было отдельным проектом, релиз превратился в еженедельный поезд с ручным согласованием, а сквозная отладка стала квестом на внимательность. Скорость упала в разы, и это при том, что технически всё было сделано аккуратно.
Микросервисы честно выигрывают там, где границы сервисов совпадают с границами команд и с границами ответственности за данные. Когда у вас пять независимых команд, у каждой свой цикл релиза, свои требования к нагрузке и свой стек, когда нужно изолировать сбой, чтобы падение рекомендаций не роняло оплату, когда есть отдельная платформенная команда, которая держит CI/CD, наблюдаемость и дежурства — вот тогда разделение реально ускоряет. Заметьте: ускоряет не потому, что это микросервисы, а потому что снимает необходимость согласовывать каждое изменение со всеми.
Монолит, в свою очередь, выигрывает там, где продукт ещё ищет рынок, домен не устоялся, а команда меньше двадцати-тридцати человек. И мой любимый ответ на вечный спор в 2025 году — модульный монолит. Одна сборка, одна база, один деплой, но жёсткие модульные границы: никаких запросов в чужие таблицы, только через публичные интерфейсы модуля, явные контракты, запрет на циклические зависимости. Мы так делали дважды, и оба раза, когда приходило время выносить модуль в отдельный сервис, это занимало недели, а не кварталы, потому что границы уже были нарисованы и проверялись на ревью.
Если хочется практического совета, начните не с архитектуры, а с вопросов. Сколько у вас команд и кто владеет какими данными? Готовы ли вы к распределённым транзакциям и eventual consistency? Есть ли наблюдаемость, трассировка, нормальный CI/CD и человек, который встанет ночью по алерту? Есть ли платформенная команда, или её роль достанется тем же разработчикам в свободное от фич время? Если хотя бы на половину вопросов ответ «нет» или «наверное», резать рано. И помните про налог: сеть, ретраи, идемпотентность, версионирование контрактов, отдельные пайплайны, мониторинг на каждый сервис. Этот налог платится всегда, а вот дивиденды приходят только при достаточном масштабе.
Итог у меня простой: в 2025 году проигрывает не монолит и не микросервисы, а архитектура, выбранная по моде, а не по размеру задачи. Монолит убивает скорость, когда в нём двадцать команд правят одни и те же файлы. Микросервисы убивают скорость, когда их строят на четыре человека без платформы и наблюдаемости. Хорошая новость в том, что это не приговор: модульный монолит прекрасно эволюционирует в сервисы, если границы модулей честные, а сервисы можно аккуратно склеить обратно, если разделение оказалось преждевременным. А теперь вопрос к вам, форумчане: какой путь вы выбрали в 2025 году и какой момент стал для вас главным сигналом, что пора что-то менять? Расскажите, что сработало — уверен, ваш опыт сэкономит кому-то пару месяцев жизни.
Первый мой опыт был как раз с монолитом. Продукт, четыре разработчика, одна кодовая база, один пайплайн, деплой за пятнадцать минут. Новую фичу мы выкатывали за пару дней, включая код, тесты и релиз, а отладка сквозного сценария занимала один прогон в IDE. Мы тогда шутили, что монолит — это наш скрытый конкурентный бонус: пока конкуренты согласовывали контракты между сервисами, мы просто меняли функцию и шли дальше.
Второй опыт был уже в компании крупнее. Сорок с лишним человек, три продуктовых направления, и решение «сделать как у взрослых»: три десятка сервисов, брокер сообщений, service mesh, отдельные репозитории у каждой команды. Через год мы получили ровно обратное тому, зачем всё это затевали. Одна пользовательская фича требовала изменений в пяти сервисах, локально поднять весь зоопарк было отдельным проектом, релиз превратился в еженедельный поезд с ручным согласованием, а сквозная отладка стала квестом на внимательность. Скорость упала в разы, и это при том, что технически всё было сделано аккуратно.
Микросервисы честно выигрывают там, где границы сервисов совпадают с границами команд и с границами ответственности за данные. Когда у вас пять независимых команд, у каждой свой цикл релиза, свои требования к нагрузке и свой стек, когда нужно изолировать сбой, чтобы падение рекомендаций не роняло оплату, когда есть отдельная платформенная команда, которая держит CI/CD, наблюдаемость и дежурства — вот тогда разделение реально ускоряет. Заметьте: ускоряет не потому, что это микросервисы, а потому что снимает необходимость согласовывать каждое изменение со всеми.
Монолит, в свою очередь, выигрывает там, где продукт ещё ищет рынок, домен не устоялся, а команда меньше двадцати-тридцати человек. И мой любимый ответ на вечный спор в 2025 году — модульный монолит. Одна сборка, одна база, один деплой, но жёсткие модульные границы: никаких запросов в чужие таблицы, только через публичные интерфейсы модуля, явные контракты, запрет на циклические зависимости. Мы так делали дважды, и оба раза, когда приходило время выносить модуль в отдельный сервис, это занимало недели, а не кварталы, потому что границы уже были нарисованы и проверялись на ревью.
Если хочется практического совета, начните не с архитектуры, а с вопросов. Сколько у вас команд и кто владеет какими данными? Готовы ли вы к распределённым транзакциям и eventual consistency? Есть ли наблюдаемость, трассировка, нормальный CI/CD и человек, который встанет ночью по алерту? Есть ли платформенная команда, или её роль достанется тем же разработчикам в свободное от фич время? Если хотя бы на половину вопросов ответ «нет» или «наверное», резать рано. И помните про налог: сеть, ретраи, идемпотентность, версионирование контрактов, отдельные пайплайны, мониторинг на каждый сервис. Этот налог платится всегда, а вот дивиденды приходят только при достаточном масштабе.
Итог у меня простой: в 2025 году проигрывает не монолит и не микросервисы, а архитектура, выбранная по моде, а не по размеру задачи. Монолит убивает скорость, когда в нём двадцать команд правят одни и те же файлы. Микросервисы убивают скорость, когда их строят на четыре человека без платформы и наблюдаемости. Хорошая новость в том, что это не приговор: модульный монолит прекрасно эволюционирует в сервисы, если границы модулей честные, а сервисы можно аккуратно склеить обратно, если разделение оказалось преждевременным. А теперь вопрос к вам, форумчане: какой путь вы выбрали в 2025 году и какой момент стал для вас главным сигналом, что пора что-то менять? Расскажите, что сработало — уверен, ваш опыт сэкономит кому-то пару месяцев жизни.