Когда я запускал первый стартап, мы спорили о микросервисах и монолите почти на каждой планёрке. Я был за микросервисы: казалось, что так мы получим масштабируемость, независимые команды и современную архитектуру. Мы выбрали микросервисы с первых дней, хотя продукт ещё толком не понимали.
Нажать чтобы Перейти на сайт
На бумаге всё выглядело красиво: отдельные сервисы для пользователей, платежей и уведомлений. На практике мы получили пять сервисов, Kubernetes, CI/CD, очереди и мониторинг. Продукт менялся каждый день, а мы тратили больше времени на инфраструктуру, чем на фичи.
Каждый релиз превращался в квест: версии API, сетевые задержки, распределённые транзакции и поиск логов по десяти дашбордам. Мы наняли DevOps раньше, чем нашли product-market fit. Это чуть не убило стартап, потому что скорость обучения упала.
Во втором проекте я сознательно начал с модульного монолита. Один репозиторий, одна база, но чёткие модули и границы. Это позволило быстро запустить MVP, спокойно делать рефакторинг и не платить за сложность, которая пока не нужна.
Узнать подробнее →
Мой вывод: для стартапа на ранней стадии монолит почти всегда выигрывает. Микросервисы стоит вводить, когда есть стабильные домены, нагрузка, несколько команд и понимание, что именно выделять. Не наоборот: сначала микросервисы, потом поиск задачи.
Главное — не религия, а скорость обучения и цена изменений. Я бы выбирал монолит до product-market fit, а потом эволюционно выделял сервисы там, где это реально болит. А какой подход выбрали вы в своём стартапе и почему?
По теме советую почитать: Low-code для бизнеса: когда экономия оборачивается долгом
Нажать чтобы Перейти на сайтНа бумаге всё выглядело красиво: отдельные сервисы для пользователей, платежей и уведомлений. На практике мы получили пять сервисов, Kubernetes, CI/CD, очереди и мониторинг. Продукт менялся каждый день, а мы тратили больше времени на инфраструктуру, чем на фичи.
Каждый релиз превращался в квест: версии API, сетевые задержки, распределённые транзакции и поиск логов по десяти дашбордам. Мы наняли DevOps раньше, чем нашли product-market fit. Это чуть не убило стартап, потому что скорость обучения упала.
Во втором проекте я сознательно начал с модульного монолита. Один репозиторий, одна база, но чёткие модули и границы. Это позволило быстро запустить MVP, спокойно делать рефакторинг и не платить за сложность, которая пока не нужна.
Узнать подробнее →Мой вывод: для стартапа на ранней стадии монолит почти всегда выигрывает. Микросервисы стоит вводить, когда есть стабильные домены, нагрузка, несколько команд и понимание, что именно выделять. Не наоборот: сначала микросервисы, потом поиск задачи.
Главное — не религия, а скорость обучения и цена изменений. Я бы выбирал монолит до product-market fit, а потом эволюционно выделял сервисы там, где это реально болит. А какой подход выбрали вы в своём стартапе и почему?
По теме советую почитать: Low-code для бизнеса: когда экономия оборачивается долгом