Alex.Popov
Member
Когда я запускал свой первый SaaS для малого бизнеса, я сразу задумался о микросервисах. Мне казалось, что так делают взрослые компании, а монолит — удел новичков. На практике я получил больше сложности, чем пользы.
Нажать чтобы Перейти на сайт
Мы с командой из трёх человек начали делать сервис бронирования. Разбили его на API Gateway, сервис пользователей, сервис платежей и уведомлений. Уже через месяц поняли, что тратим больше времени на инфраструктуру, Docker, очереди и деплой, чем на функции для клиентов.
Потом я переписал проект в модульный монолит. Один код, одна база, но с чёткими границами между модулями. Это дало скорость: я мог за день добавить новую функцию и не согласовывать контракты между сервисами. Для малого бизнеса, где важно проверить гипотезу, монолит оказался эффективнее.
Микросервисы имеют смысл, когда у вас уже есть стабильный продукт, несколько команд, разные нагрузки и потребность масштабировать отдельные части. Но если вы только ищете рынок, микросервисы — это дорогое удовольствие. Они добавляют сетевые задержки, распределённые транзакции, мониторинг и сложность поддержки.
Узнать подробнее →
Я не говорю, что монолит всегда лучше. Важно проектировать модули так, чтобы позже их можно было вынести. Я использую принцип: сначала монолит с понятными границами, потом, при реальной боли, выделяю сервисы. Это позволяет не платить за сложность заранее.
В итоге для малого бизнеса я рекомендую начинать с монолита, если нет сильной команды DevOps и острой необходимости. А вы что выбрали в своём проекте: монолит или микросервисы, и почему?
По теме советую почитать: Микросервисы или монолит: что выбрать малому бизнесу
Нажать чтобы Перейти на сайтМы с командой из трёх человек начали делать сервис бронирования. Разбили его на API Gateway, сервис пользователей, сервис платежей и уведомлений. Уже через месяц поняли, что тратим больше времени на инфраструктуру, Docker, очереди и деплой, чем на функции для клиентов.
Потом я переписал проект в модульный монолит. Один код, одна база, но с чёткими границами между модулями. Это дало скорость: я мог за день добавить новую функцию и не согласовывать контракты между сервисами. Для малого бизнеса, где важно проверить гипотезу, монолит оказался эффективнее.
Микросервисы имеют смысл, когда у вас уже есть стабильный продукт, несколько команд, разные нагрузки и потребность масштабировать отдельные части. Но если вы только ищете рынок, микросервисы — это дорогое удовольствие. Они добавляют сетевые задержки, распределённые транзакции, мониторинг и сложность поддержки.
Узнать подробнее →Я не говорю, что монолит всегда лучше. Важно проектировать модули так, чтобы позже их можно было вынести. Я использую принцип: сначала монолит с понятными границами, потом, при реальной боли, выделяю сервисы. Это позволяет не платить за сложность заранее.
В итоге для малого бизнеса я рекомендую начинать с монолита, если нет сильной команды DevOps и острой необходимости. А вы что выбрали в своём проекте: монолит или микросервисы, и почему?
По теме советую почитать: Микросервисы или монолит: что выбрать малому бизнесу