Viktor_Belov328
New member
Когда я запускал свой первый стартап — SaaS-платформу для логистических компаний, я тратил недели на споры с командой о том, строить ли систему на микросервисах или сразу делать монолит. Тогда, в 2018 году, мода на микросервисы была на пике, и каждый второй ментор на демо-днях советовал разбивать всё сразу на сервисы. Мы послушали — и через три месяца обнаружили, что 60% нашего времени уходило не на разработку функций, а на управление инфраструктурой, оркестрацию и отладку распределённых вызовов. Мы не успевали к рынку.
Нажать чтобы Перейти на сайт
Через год я запустил второй проект, и на этот раз сознательно выбрал монолит на Spring Boot. Команда из трёх человек разворачивала сервис на Heroku за десять минут, деплой был простым, отладка — предсказуемой. Мы вышли на первых клиентов за восемь недель. Парадокс в том, что именно монолитная архитектура дала нам гибкость и скорость, которые обычно ассоциируют с микросервисами. Для стартапа на стадии поиска product-market fit это оказалось критическим преимуществом.
Мой опыт не означает, что микросервисы — зло. Они оправдывают себя, когда у вас уже есть устойчивая бизнес-модель, команда из десятков разработчиков и реальные требования к независимому масштабированию отдельных компонентов. В микросервисах есть сила, но эта сила требует зрелости. Я видел стартапы, которые сжигали инвестиции не на продукт, а на то, чтобы просто удержать в рабочем состоянии сеть из пятнадцати сервисов, которые общаются между собой через очередь сообщений и API-шлюзы.
Если говорить о компромиссах, то я сейчас придерживаюсь подхода, который можно назвать «модульный монолит». В одном приложении чётко разделённые модули с явными границами и контрактами, которые при необходимости можно вынести в отдельные сервисы без переписывания кода. Это позволяет получить организованность микросервисной архитектуры, сохранив простоту деплоя и отладки монолита. Для команды до десяти человек это, на мой взгляд, оптимальная стратегия.
Узнать подробнее →
Конечно, решение всегда зависит от контекста. Если вы строите платформу с высоконагруженной нагрузкой на определённый компонент или работаете с командой распределённых специалистов в разных часовых поясах, микросервисы могут быть оправданы с самого начала. Но в большинстве случаев, особенно для ранних стадий, я убеждён: выбирайте монолит, думайте о микросервисах тогда, когда боль от монолита станет реальнее боли от его ограничений.
А как вы решаете этот вопрос в своих проектах? Есть ли у вас опыт, когда выбранный архитектурный стиль оказался ошибкой — или, наоборот, спас проект? Делитесь в комментариях.
По теме советую почитать: ИИ в малом бизнесе: инструменты, риски и мой опыт
Нажать чтобы Перейти на сайтЧерез год я запустил второй проект, и на этот раз сознательно выбрал монолит на Spring Boot. Команда из трёх человек разворачивала сервис на Heroku за десять минут, деплой был простым, отладка — предсказуемой. Мы вышли на первых клиентов за восемь недель. Парадокс в том, что именно монолитная архитектура дала нам гибкость и скорость, которые обычно ассоциируют с микросервисами. Для стартапа на стадии поиска product-market fit это оказалось критическим преимуществом.
Мой опыт не означает, что микросервисы — зло. Они оправдывают себя, когда у вас уже есть устойчивая бизнес-модель, команда из десятков разработчиков и реальные требования к независимому масштабированию отдельных компонентов. В микросервисах есть сила, но эта сила требует зрелости. Я видел стартапы, которые сжигали инвестиции не на продукт, а на то, чтобы просто удержать в рабочем состоянии сеть из пятнадцати сервисов, которые общаются между собой через очередь сообщений и API-шлюзы.
Если говорить о компромиссах, то я сейчас придерживаюсь подхода, который можно назвать «модульный монолит». В одном приложении чётко разделённые модули с явными границами и контрактами, которые при необходимости можно вынести в отдельные сервисы без переписывания кода. Это позволяет получить организованность микросервисной архитектуры, сохранив простоту деплоя и отладки монолита. Для команды до десяти человек это, на мой взгляд, оптимальная стратегия.
Узнать подробнее →Конечно, решение всегда зависит от контекста. Если вы строите платформу с высоконагруженной нагрузкой на определённый компонент или работаете с командой распределённых специалистов в разных часовых поясах, микросервисы могут быть оправданы с самого начала. Но в большинстве случаев, особенно для ранних стадий, я убеждён: выбирайте монолит, думайте о микросервисах тогда, когда боль от монолита станет реальнее боли от его ограничений.
А как вы решаете этот вопрос в своих проектах? Есть ли у вас опыт, когда выбранный архитектурный стиль оказался ошибкой — или, наоборот, спас проект? Делитесь в комментариях.
По теме советую почитать: ИИ в малом бизнесе: инструменты, риски и мой опыт