Alex.Miller
Member
Год назад я начал рефакторинг проекта, который разрабатывал для небольшой сети кофеен. Клиент просил «как у больших компаний» — микросервисы, контейнеры, Kubernetes. Я согласился, потому что хотел показать себя в современном стеке. Через два месяца мы понимали, что создали себе ад: шесть сервисов, каждый с собственным логом, собственным деплоем и собственными багами.
Нажать чтобы Перейти на сайт
Когда владелец кофейни сказал, что ему нужно просто поменять цену в меню, я тратил на это полдня. Изменения в одном сервисе ломали интеграцию с другим, и debugging превращался в квест. При мономорфной архитектуре это была бы одна строка в одном файле. Малый бизнес не платит за инфраструктуру — он платит за результат, а не за «современность».
Ещё один момент, который я понял на своём горьком опыте: микросервисы требуют команды, которая умеет и хочет работать с распределёнными системами. У меня в проекте был один разработчик — я сам — и одна дизайнер-исполнитель. Нам не хватало даже рук, чтобы поднимать и поддерживать один сервис, не говоря уже о шести. Нет SRE, нет DevOps-инженера — значит, всё ложится на разработчика, который ещё и код должен писать.
Мониторинг и наблюдаемость в микросервисной архитектуре — это отдельная наука. Дистрибутивный трассинг, централизованное логирование, health checks для каждого сервиса. Для корпорации с бюджетом в миллионы это норма. Для малого бизнеса, где каждый рубль на счету, это роскошь, которая съедает ресурс без прямой пользы для клиента.
Узнать подробнее →
Я в итоге вернул проект к модульной монолитной архитектуре. Выделил бизнес-домены внутри одного приложения, оставил чистый код, но убрал сетевые вызовы между сервисами. Проект стал проще, деплой — быстрее, а владелец кофейни наконец смог менять меню за пять минут через админку. Производительность выросла, а поддержка упала в разы.
Это не значит, что микросервисы — зло. Они отлично работают там, где есть масштаб, команда и реальные доменные границы. Но малому бизнесу чаще всего хватает модульного монолита с хорошей структурой. Вопрос к вам: а вы когда-нибудь сталкивались с ситуацией, когда микросервисная архитектура оказалась избыточной для задачи? Какие признаки помогают понять, что пора упростить?
По теме советую почитать: CI/CD: как мы сократили время релиза в 4 раза
Нажать чтобы Перейти на сайтКогда владелец кофейни сказал, что ему нужно просто поменять цену в меню, я тратил на это полдня. Изменения в одном сервисе ломали интеграцию с другим, и debugging превращался в квест. При мономорфной архитектуре это была бы одна строка в одном файле. Малый бизнес не платит за инфраструктуру — он платит за результат, а не за «современность».
Ещё один момент, который я понял на своём горьком опыте: микросервисы требуют команды, которая умеет и хочет работать с распределёнными системами. У меня в проекте был один разработчик — я сам — и одна дизайнер-исполнитель. Нам не хватало даже рук, чтобы поднимать и поддерживать один сервис, не говоря уже о шести. Нет SRE, нет DevOps-инженера — значит, всё ложится на разработчика, который ещё и код должен писать.
Мониторинг и наблюдаемость в микросервисной архитектуре — это отдельная наука. Дистрибутивный трассинг, централизованное логирование, health checks для каждого сервиса. Для корпорации с бюджетом в миллионы это норма. Для малого бизнеса, где каждый рубль на счету, это роскошь, которая съедает ресурс без прямой пользы для клиента.
Узнать подробнее →Я в итоге вернул проект к модульной монолитной архитектуре. Выделил бизнес-домены внутри одного приложения, оставил чистый код, но убрал сетевые вызовы между сервисами. Проект стал проще, деплой — быстрее, а владелец кофейни наконец смог менять меню за пять минут через админку. Производительность выросла, а поддержка упала в разы.
Это не значит, что микросервисы — зло. Они отлично работают там, где есть масштаб, команда и реальные доменные границы. Но малому бизнесу чаще всего хватает модульного монолита с хорошей структурой. Вопрос к вам: а вы когда-нибудь сталкивались с ситуацией, когда микросервисная архитектура оказалась избыточной для задачи? Какие признаки помогают понять, что пора упростить?
По теме советую почитать: CI/CD: как мы сократили время релиза в 4 раза