Я больше десяти лет пишу код и запускаю продукты, и за это время успел поработать и с монолитами, и с микросервисами. Последние пару лет я руководил небольшой командой из пяти человек, и мы прошли через болезненный, но полезный эксперимент: сначала разнесли систему на сервисы, а потом частично вернулись к модульному монолиту. Хочу честно рассказать, почему для маленькой команды микросервисы часто оказываются дороже, чем кажутся на слайдах.
Микросервисная архитектура красиво звучит: независимые развёртывания, отдельные базы, масштабирование по потребностям, разные технологии под задачи. Но у этой красоты есть цена, и в команде из пяти человек она особенно заметна. Каждый сервис требует инфраструктуры, мониторинга, логирования, контрактов, непрерывной интеграции и доставки, обработки ошибок. Даже если нет отдельного специалиста по эксплуатации, эти обязанности размазываются по разработчикам и съедают время на продукт.
В нашем случае мы выделили шесть сервисов: авторизацию, биллинг, каталог, заказы, уведомления и аналитику. На бумаге границы были логичными. В реальности любая функция вроде скидки на товар требовала изменений в трёх сервисах, согласования программных интерфейсов и синхронных выпусков. Вместо скорости мы получили распределённую связанность и постоянные вопросы: кто владелец данных, как откатывать, что делать с частичными сбоями.
Отладка тоже превратилась в квест. Локально поднять всю систему стало сложно, поэтому мы чаще тестировали в общем окружении. Ошибка в одном сервисе могла выглядеть как проблема в другом, а трассировка и идентификатор запроса появились не сразу. Плюс распределённые транзакции и постепенная согласованность — это темы, которые маленькой команде без сильного опыта даются дорого. Мы тратили больше времени на инфраструктуру, чем на пользовательскую ценность.
Когда монолит дешевле? Почти всегда, если продукт ещё ищет рынок, команда меньше семи-восьми человек, нет выделенной платформенной команды, а предметная область пока плохо изучена. Монолит с чёткими модулями даёт быстрый старт, одно развёртывание, простую отладку и меньше когнитивной нагрузки. Важно не превращать его в большой комок грязи: держите границы модулей, запрещайте хаотичные зависимости и пишите тесты.
При этом я не говорю, что микросервисы — зло. Они оправданы, когда есть реальная причина: разные нагрузки, изоляция критичного компонента, независимые команды или требование масштабировать часть системы отдельно. Но для пяти человек чаще выгоднее модульный монолит, а затем постепенное выделение сервисов по мере роста боли. Не надо платить за распределённую систему заранее.
Мой главный вывод: архитектура должна соответствовать размеру команды и зрелости продукта, а не наоборот. Начните с монолита, измеряйте узкие места, автоматизируйте тесты и развёртывание, а микросервисы выделяйте только там, где они решают конкретную проблему. Тогда вы сохраните скорость и не утонете в инфраструктуре. А что вы выбирали для своих небольших команд — монолит или микросервисы, и какой полезный урок вы вынесли?
Микросервисная архитектура красиво звучит: независимые развёртывания, отдельные базы, масштабирование по потребностям, разные технологии под задачи. Но у этой красоты есть цена, и в команде из пяти человек она особенно заметна. Каждый сервис требует инфраструктуры, мониторинга, логирования, контрактов, непрерывной интеграции и доставки, обработки ошибок. Даже если нет отдельного специалиста по эксплуатации, эти обязанности размазываются по разработчикам и съедают время на продукт.
В нашем случае мы выделили шесть сервисов: авторизацию, биллинг, каталог, заказы, уведомления и аналитику. На бумаге границы были логичными. В реальности любая функция вроде скидки на товар требовала изменений в трёх сервисах, согласования программных интерфейсов и синхронных выпусков. Вместо скорости мы получили распределённую связанность и постоянные вопросы: кто владелец данных, как откатывать, что делать с частичными сбоями.
Отладка тоже превратилась в квест. Локально поднять всю систему стало сложно, поэтому мы чаще тестировали в общем окружении. Ошибка в одном сервисе могла выглядеть как проблема в другом, а трассировка и идентификатор запроса появились не сразу. Плюс распределённые транзакции и постепенная согласованность — это темы, которые маленькой команде без сильного опыта даются дорого. Мы тратили больше времени на инфраструктуру, чем на пользовательскую ценность.
Когда монолит дешевле? Почти всегда, если продукт ещё ищет рынок, команда меньше семи-восьми человек, нет выделенной платформенной команды, а предметная область пока плохо изучена. Монолит с чёткими модулями даёт быстрый старт, одно развёртывание, простую отладку и меньше когнитивной нагрузки. Важно не превращать его в большой комок грязи: держите границы модулей, запрещайте хаотичные зависимости и пишите тесты.
При этом я не говорю, что микросервисы — зло. Они оправданы, когда есть реальная причина: разные нагрузки, изоляция критичного компонента, независимые команды или требование масштабировать часть системы отдельно. Но для пяти человек чаще выгоднее модульный монолит, а затем постепенное выделение сервисов по мере роста боли. Не надо платить за распределённую систему заранее.
Мой главный вывод: архитектура должна соответствовать размеру команды и зрелости продукта, а не наоборот. Начните с монолита, измеряйте узкие места, автоматизируйте тесты и развёртывание, а микросервисы выделяйте только там, где они решают конкретную проблему. Тогда вы сохраните скорость и не утонете в инфраструктуре. А что вы выбирали для своих небольших команд — монолит или микросервисы, и какой полезный урок вы вынесли?