Anton.Petrov
New member
Год назад я почти совершил серьёзную ошибку: собирался разорвать наш монолитный бэкенд на микросервисы, потому что «так принято в 2025-м». Но прежде чем кинуться в эту перестройку, я посидел и посчитал. Арифметика вышла удручающая: только на инфраструктуру, мониторинг, CI/CD для каждого сервиса и найм людей, которые умеют это всё поддерживать, мы бы ежемесячно доплачивали в два раза больше, чем сейчас тратим на монолит. Это подтолкнуло меня глубже разобраться в вопросе, и сейчас я хочу поделиться выводами с теми, кто стоит перед тем же выбором.
Мой проект — это средний SaaS для управления логистикой. До недавнего времени всё работало как монолит на Node.js с PostgreSQL. Команда из шести разработчиков, дефолы каждые две недели, uptime стабильный. И вот в какой-то момент продукт начал расти: добавились интеграции с тремя внешними системами, нагрузка подскочила вдвое, а один кривой деплой начал отваливать не только модуль заказов, но и панель аналитики. Тогда и началось давление на микросервисы.
Я провёл три месяца исследований и параллельно создал proof-of-concept: вынес модуль интеграций в отдельный сервис на Go с отдельной БД. Технически всё сработало — модуль стал деплоиться независимо, при его падении остальная система не страдала. Но运营成本 выросли ощутимо: пришлось завести отдельный Kubernetes-кластер, настроить распределённый трассировку, написать оркестрацию вызовов между сервисами, а ещё нанять человека, который разберётся в этой инфраструктуре. Итого минус два человека из продуктивной команды на год.
После этого я осознал главное: микросервисы — это не цель, а инструмент. Они оправдывают себя, когда у тебя десятки команд, которые независимо развивают разные домены, когда отдельные модули имеют радикально разные требования к масштабированию или стеку, когда合规ность требует изоляции данных. Если же у тебя команда до двадцати человек и продукт растёт линейно — монолит, даже современный, с чётким модульным разделением кода внутри, будет дешевле, быстрее и надёжнее.
В 2025 году я бы рекомендовал следующую стратегию: начинай с монолита, но проектируй его как «модульный монолит» — чёткие доменные границы, слабая связанность модулей, контракты между ними. Это даст тебе 80 процентов гибкости микросервисов без 100 процентов их стоимости. А когда конкретный модуль действительно упрётся в потолок — выноси его первым, по одному, с замером эффекта. Не разрывай всё сразу по идеологии.
Ещё один момент, который для меня стал открытием: инфраструктура в облаках сильно подешевела в обслуживании. Serverless, managed containers, готовые решения для оркестрации — всё это снижает порог входа в микросервисы. Но это не значит, что они стали бесплатными. Скрытые издержки — время отладки, когнитивная нагрузка на команду, дублирование зависимостей — по-прежнему значительны. Я лично убедился в этом, когда один баг в общей библиотеке потребовал обновлений в четырёх сервисах одновременно.
В итоге я не разорвал монолит полностью. Я вынес только модуль интеграций, который действительно страдал от несовместимых требований к надёжности и стеку. Остальная система осталась монолитной, но теперь с жёсткой модульной архитектурой. Бюджет не вырос, команда не расползлась по инфраструктуре, а больная точка исцелилась. Для меня это был самый грамотный компромисс.
Коллеги, а как вы решали этот вопрос в своих проектах? С чего начинали — с монолита или сразу с микросервисов, и что сработало лучше? Делитесь опытом, мне правда интересно услышать разные истории!
Мой проект — это средний SaaS для управления логистикой. До недавнего времени всё работало как монолит на Node.js с PostgreSQL. Команда из шести разработчиков, дефолы каждые две недели, uptime стабильный. И вот в какой-то момент продукт начал расти: добавились интеграции с тремя внешними системами, нагрузка подскочила вдвое, а один кривой деплой начал отваливать не только модуль заказов, но и панель аналитики. Тогда и началось давление на микросервисы.
Я провёл три месяца исследований и параллельно создал proof-of-concept: вынес модуль интеграций в отдельный сервис на Go с отдельной БД. Технически всё сработало — модуль стал деплоиться независимо, при его падении остальная система не страдала. Но运营成本 выросли ощутимо: пришлось завести отдельный Kubernetes-кластер, настроить распределённый трассировку, написать оркестрацию вызовов между сервисами, а ещё нанять человека, который разберётся в этой инфраструктуре. Итого минус два человека из продуктивной команды на год.
После этого я осознал главное: микросервисы — это не цель, а инструмент. Они оправдывают себя, когда у тебя десятки команд, которые независимо развивают разные домены, когда отдельные модули имеют радикально разные требования к масштабированию или стеку, когда合规ность требует изоляции данных. Если же у тебя команда до двадцати человек и продукт растёт линейно — монолит, даже современный, с чётким модульным разделением кода внутри, будет дешевле, быстрее и надёжнее.
В 2025 году я бы рекомендовал следующую стратегию: начинай с монолита, но проектируй его как «модульный монолит» — чёткие доменные границы, слабая связанность модулей, контракты между ними. Это даст тебе 80 процентов гибкости микросервисов без 100 процентов их стоимости. А когда конкретный модуль действительно упрётся в потолок — выноси его первым, по одному, с замером эффекта. Не разрывай всё сразу по идеологии.
Ещё один момент, который для меня стал открытием: инфраструктура в облаках сильно подешевела в обслуживании. Serverless, managed containers, готовые решения для оркестрации — всё это снижает порог входа в микросервисы. Но это не значит, что они стали бесплатными. Скрытые издержки — время отладки, когнитивная нагрузка на команду, дублирование зависимостей — по-прежнему значительны. Я лично убедился в этом, когда один баг в общей библиотеке потребовал обновлений в четырёх сервисах одновременно.
В итоге я не разорвал монолит полностью. Я вынес только модуль интеграций, который действительно страдал от несовместимых требований к надёжности и стеку. Остальная система осталась монолитной, но теперь с жёсткой модульной архитектурой. Бюджет не вырос, команда не расползлась по инфраструктуре, а больная точка исцелилась. Для меня это был самый грамотный компромисс.
Коллеги, а как вы решали этот вопрос в своих проектах? С чего начинали — с монолита или сразу с микросервисов, и что сработало лучше? Делитесь опытом, мне правда интересно услышать разные истории!