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