Когда я запустил свой первый стартап — сервис автоматизации доставки для малого бизнеса — я, как многие «молодые» разработчики, сразу начал с микросервисов. Мне казалось, что так мы будем масштабируемы, гибки и современны. В итоге мы потратили два месяца на настройку Docker Compose, Kubernetes в песочнице и API Gateway, прежде чем написать первую бизнес-логику. За эти же два месяца в монолите мы бы уже показали MVP клиентам.
Нажать чтобы Перейти на сайт
Микросервисы дали мне «архитектурное удовольствие», но стоили команду из трёх человек, которая постоянно боролась с дистрибутивными проблемами. Сеть отваливалась, транзакции распадались, отладка превращалась в гонку по логам пяти разных сервисов. Мы потеряли двух ключевых клиентов, потому что не успевали фиксить баги, которые возникали именно на стыках между сервисами — там, где монолит даже не задумывался бы.
Через полгода мы переписали ядро системы в монолит на Node.js и PostgreSQL, сохранив только один микросервис — платёжную шлюзовую интеграцию, потому что она требует изоляции по требованиям безопасности. Скорость разработки выросла втрое, деплой стал за 30 секунд вместо 15 минут, а мониторинг перестал быть отдельным проектом.
Но я не хочу сказать, что микросервисы — это зло. Когда мой второй проект — маркетплейс — начал расти, и у нас появились независимые команды по каталогу товаров, логистике и финансам, микросервисы стали осмысленным решением. Ключевое слово — независимые команды. Если у вас один человек пишет и фронт, и бэкенд, и деплой — вам нужны не микросервисы, вам нужен простой монолит с чистой внутренней архитектурой.
Узнать подробнее →
Моё правило: начинай с монолита, который хорошо разделён на модули внутри себя. Дождись момента, когда команда выросла до пяти-шести человек, когда разные части системы действительно меняются с разной частотой, когда у вас появились реальные требования к независимому масштабированию. Только тогда вынимай модули в отдельные сервисы. До этого ты платишь за микросервисы налоговой нагрузкой на инфраструктуру и коммуникацию, а не получаешь от них выгоды.
А вы как начинали — сразу с микросервисов или с монолита? Сталкивались ли с моментом, когда пришлось переписывать архитектуру? Расскажите в комментариях — интересно посмотреть, где другие совершили ошибки, чтобы я не повторял их в третьем проекте.
По теме советую почитать: DevOps и бизнес-результаты: метрики успеха
Нажать чтобы Перейти на сайтМикросервисы дали мне «архитектурное удовольствие», но стоили команду из трёх человек, которая постоянно боролась с дистрибутивными проблемами. Сеть отваливалась, транзакции распадались, отладка превращалась в гонку по логам пяти разных сервисов. Мы потеряли двух ключевых клиентов, потому что не успевали фиксить баги, которые возникали именно на стыках между сервисами — там, где монолит даже не задумывался бы.
Через полгода мы переписали ядро системы в монолит на Node.js и PostgreSQL, сохранив только один микросервис — платёжную шлюзовую интеграцию, потому что она требует изоляции по требованиям безопасности. Скорость разработки выросла втрое, деплой стал за 30 секунд вместо 15 минут, а мониторинг перестал быть отдельным проектом.
Но я не хочу сказать, что микросервисы — это зло. Когда мой второй проект — маркетплейс — начал расти, и у нас появились независимые команды по каталогу товаров, логистике и финансам, микросервисы стали осмысленным решением. Ключевое слово — независимые команды. Если у вас один человек пишет и фронт, и бэкенд, и деплой — вам нужны не микросервисы, вам нужен простой монолит с чистой внутренней архитектурой.
Узнать подробнее →Моё правило: начинай с монолита, который хорошо разделён на модули внутри себя. Дождись момента, когда команда выросла до пяти-шести человек, когда разные части системы действительно меняются с разной частотой, когда у вас появились реальные требования к независимому масштабированию. Только тогда вынимай модули в отдельные сервисы. До этого ты платишь за микросервисы налоговой нагрузкой на инфраструктуру и коммуникацию, а не получаешь от них выгоды.
А вы как начинали — сразу с микросервисов или с монолита? Сталкивались ли с моментом, когда пришлось переписывать архитектуру? Расскажите в комментариях — интересно посмотреть, где другие совершили ошибки, чтобы я не повторял их в третьем проекте.
По теме советую почитать: DevOps и бизнес-результаты: метрики успеха