Почему микросервисы чаще вредят, чем помогают
На новой работе, я сделал то, что обычно не принято: превратил микросервисную архитектуру в монолит.
И причин тому несколько:
- команда разработки всего два человека: мы не толкались локтями в одних и тех же файлах и модулях
- каждый микросервис делал одинаковую задачу: забирал данные из ERP и отправлял в мастер систему
- 80% кода это копипаст так как нет настроенной системы для работы с приватными библиотеками
- каждый сервис эксплуатировал только 5-10% выделенных ресурсов
Нашел как раз статью на тему того, как микросервисы могут не только усложнить разработку, но и привести к увеличению time-to-market, за счет увеличения времени на тестирование и отладку.
Автор показывает, что модульный монолит часто дешевле, надёжнее и быстрее в развитии.
Микросервисы оправданы лишь в редких случаях — при зрелой команде, масштабах и чётких организационных причинах, а не из-за моды.
Возвращаясь к моему опыту, наверняка есть вопрос: “А зачем вообще появились микросервисы в команде из 2х человек?”
Они появились до меня и планировалось, что будет изолированное масштабирование работы с разными по объему клиентами. А по факту, не было (и не придвидится в ближайшем будущем) клинтов такого размера, которому нужно будет больше одной реплики сервиса.