Alex.Morozov
Member
Когда я запускал первый стартап, мы с командой из пяти человек сразу бросились строить микросервисы. Нам казалось, что так мы заложим основу для быстрого роста, независимых деплоев и масштабирования. На практике мы получили распределенную систему, которую никто не понимал целиком, а скорость разработки упала в разы.
Нажать чтобы Перейти на сайт
Мы тратили время на настройку Kubernetes, очередей, сервис-дискавери, трассировки и CI/CD для десятка сервисов. Каждая новая фича затрагивала три-четыре репозитория, а локально поднять весь ландшафт было почти невозможно. В итоге мы несколько месяцев чинили инфраструктуру вместо того, чтобы проверять продуктовые гипотезы.
Во втором проекте я сознательно начал с монолита. Мы сделали одно приложение, одну базу и один деплой. Это позволило за пару недель выпустить MVP, быстро собирать обратную связь и менять схему данных без сложных миграций между сервисами. Кодовая база была небольшой, и вся команда видела картину целиком.
Микросервисы я не считаю злом. Они оправданы, когда есть много команд, четкие доменные границы, потребность в независимом масштабировании и зрелые DevOps-процессы. Но стартапу на ранней стадии чаще не хватает именно этого: людей, процессов и стабильного понимания продукта.
Узнать подробнее →
Поэтому мой практический совет для стартапа — начинать с модульного монолита. Держите логические границы внутри кода, используйте четкие интерфейсы и события, но не платите цену распределенной системы раньше времени. Выделяйте сервис только тогда, когда боль от монолита станет реальной и измеримой.
Сейчас я бы выбрал монолит для MVP и почти наверняка остался бы на нем до этапа активного роста. Микросервисы — это инструмент для масштаба и организации, а не способ сделать стартап быстрее. А вы что выбрали в своем проекте и почему?
По теме советую почитать: Удалённая команда в IT: управление и мотивация
Нажать чтобы Перейти на сайтМы тратили время на настройку Kubernetes, очередей, сервис-дискавери, трассировки и CI/CD для десятка сервисов. Каждая новая фича затрагивала три-четыре репозитория, а локально поднять весь ландшафт было почти невозможно. В итоге мы несколько месяцев чинили инфраструктуру вместо того, чтобы проверять продуктовые гипотезы.
Во втором проекте я сознательно начал с монолита. Мы сделали одно приложение, одну базу и один деплой. Это позволило за пару недель выпустить MVP, быстро собирать обратную связь и менять схему данных без сложных миграций между сервисами. Кодовая база была небольшой, и вся команда видела картину целиком.
Микросервисы я не считаю злом. Они оправданы, когда есть много команд, четкие доменные границы, потребность в независимом масштабировании и зрелые DevOps-процессы. Но стартапу на ранней стадии чаще не хватает именно этого: людей, процессов и стабильного понимания продукта.
Узнать подробнее →Поэтому мой практический совет для стартапа — начинать с модульного монолита. Держите логические границы внутри кода, используйте четкие интерфейсы и события, но не платите цену распределенной системы раньше времени. Выделяйте сервис только тогда, когда боль от монолита станет реальной и измеримой.
Сейчас я бы выбрал монолит для MVP и почти наверняка остался бы на нем до этапа активного роста. Микросервисы — это инструмент для масштаба и организации, а не способ сделать стартап быстрее. А вы что выбрали в своем проекте и почему?
По теме советую почитать: Удалённая команда в IT: управление и мотивация