Design_Artyom
New member
Привет, коллеги. Хочу поделиться своим опытом, потому что этот вопрос мне задают почти на каждом созвоне с основателями, и я уже устал отвечать односложно. За последние семь лет я запускал три продукта: два на монолите и один сразу на микросервисах. И знаете что? Самый болезненный провал случился именно там, где мы решили «сделать сразу правильно и по-взрослому».
Начну с контекста. В 2022 году мы с командой из четырёх человек подняли маркетплейс услуг. Архитектуру выбрали микросервисную, потому что так писали в умных статьях, а ещё потому, что мне хотелось красивое резюме. Мы нарезали восемь сервисов, настроили брокер сообщений, подняли Kubernetes, завели отдельный шлюз и полноценный мониторинг. Через полгода у нас было примерно ноль постоянных пользователей и бесконечная боль при каждом деплое. Изменение одной кнопки в интерфейсе превращалось в трёхдневный квест по согласованию контрактов между сервисами.
Второй проект стартовал с противоположной крайности. Один репозиторий, одна база, одно приложение, которое мы выкатывали на простом виртуальном сервере. Мы писали код прямо в проде в понедельник утром, и, честно говоря, это было счастье. Первую тысячу платящих клиентов мы прошли вообще без архитектурных страданий. Монолит не мешает вам искать product-market fit, а вот микросервисы очень даже мешают, потому что съедают всё ваше внимание на инфраструктуру.
Но я не хочу быть тем парнем, который просто хейтит распределённые системы. Истина в том, что микросервисы — это не архитектурный выбор, а организационный. Они решают проблему координации между командами, а не проблему технической производительности. Если у вас пятнадцать разработчиков и три независимых продуктовых направления, монолит начнёт трещать по швам: релизы будут блокировать друг друга, а конфликты в коде превратятся в ежедневный ритуал. Вот тогда микросервисы реально спасают.
Для стартапа в 2025 году я бы сформулировал правило так: если вы можете описать свою команду на одной ладони, вам нужен монолит. Модульный монолит, если хочется быть аккуратным — с чёткими границами между доменами внутри одного приложения. Это даёт вам 90 процентов пользы микросервисов и почти ноль их боли. Вы всё ещё можете позже вынести горячий модуль в отдельный сервис, когда появится реальная причина, а не гипотетическая.
Отдельно скажу про 2025 год и моду. Сейчас инструменты стали гораздо дружелюбнее: контейнеры, платформы для деплоя, готовые решения для очередей и кэша. Соблазн огромный. Но запомните главную мысль: инфраструктурная сложность — это налог, который вы платите за масштаб, которого у вас ещё нет. Платить налог заранее — плохая инвестиция. Гораздо лучше потратить эти деньги и нервы на разговоры с клиентами.
Моя рекомендация читателям проста. Начинайте с монолита, даже если это выглядит несовременно. Пишите код так, чтобы его можно было разделить позже: не смешивайте бизнес-логику с транспортом, держите домены изолированными, документируйте границы. И только когда почувствуете настоящую боль — не модную, а ту, от которой ноют зубы и падают релизы, — начинайте отрезать первый сервис. Самый честный критерий звучит так: переходите на микросервисы, когда количество людей в команде или частота изменений начнут мешать сильнее, чем стоимость распределённой системы. Ни секундой раньше.
А теперь вопрос к вам, форумчане: на каком этапе вашего проекта вы честно поняли, что монолит больше не тянет, и какой первый сервис вы вынесли в отдельный процесс? Поделитесь историями, у кого что сработало — очень интересно сверить опыт!
Начну с контекста. В 2022 году мы с командой из четырёх человек подняли маркетплейс услуг. Архитектуру выбрали микросервисную, потому что так писали в умных статьях, а ещё потому, что мне хотелось красивое резюме. Мы нарезали восемь сервисов, настроили брокер сообщений, подняли Kubernetes, завели отдельный шлюз и полноценный мониторинг. Через полгода у нас было примерно ноль постоянных пользователей и бесконечная боль при каждом деплое. Изменение одной кнопки в интерфейсе превращалось в трёхдневный квест по согласованию контрактов между сервисами.
Второй проект стартовал с противоположной крайности. Один репозиторий, одна база, одно приложение, которое мы выкатывали на простом виртуальном сервере. Мы писали код прямо в проде в понедельник утром, и, честно говоря, это было счастье. Первую тысячу платящих клиентов мы прошли вообще без архитектурных страданий. Монолит не мешает вам искать product-market fit, а вот микросервисы очень даже мешают, потому что съедают всё ваше внимание на инфраструктуру.
Но я не хочу быть тем парнем, который просто хейтит распределённые системы. Истина в том, что микросервисы — это не архитектурный выбор, а организационный. Они решают проблему координации между командами, а не проблему технической производительности. Если у вас пятнадцать разработчиков и три независимых продуктовых направления, монолит начнёт трещать по швам: релизы будут блокировать друг друга, а конфликты в коде превратятся в ежедневный ритуал. Вот тогда микросервисы реально спасают.
Для стартапа в 2025 году я бы сформулировал правило так: если вы можете описать свою команду на одной ладони, вам нужен монолит. Модульный монолит, если хочется быть аккуратным — с чёткими границами между доменами внутри одного приложения. Это даёт вам 90 процентов пользы микросервисов и почти ноль их боли. Вы всё ещё можете позже вынести горячий модуль в отдельный сервис, когда появится реальная причина, а не гипотетическая.
Отдельно скажу про 2025 год и моду. Сейчас инструменты стали гораздо дружелюбнее: контейнеры, платформы для деплоя, готовые решения для очередей и кэша. Соблазн огромный. Но запомните главную мысль: инфраструктурная сложность — это налог, который вы платите за масштаб, которого у вас ещё нет. Платить налог заранее — плохая инвестиция. Гораздо лучше потратить эти деньги и нервы на разговоры с клиентами.
Моя рекомендация читателям проста. Начинайте с монолита, даже если это выглядит несовременно. Пишите код так, чтобы его можно было разделить позже: не смешивайте бизнес-логику с транспортом, держите домены изолированными, документируйте границы. И только когда почувствуете настоящую боль — не модную, а ту, от которой ноют зубы и падают релизы, — начинайте отрезать первый сервис. Самый честный критерий звучит так: переходите на микросервисы, когда количество людей в команде или частота изменений начнут мешать сильнее, чем стоимость распределённой системы. Ни секундой раньше.
А теперь вопрос к вам, форумчане: на каком этапе вашего проекта вы честно поняли, что монолит больше не тянет, и какой первый сервис вы вынесли в отдельный процесс? Поделитесь историями, у кого что сработало — очень интересно сверить опыт!