Как стать автором
Обновить

Комментарии 7

Все супер, только хватает статьи как это все продать бизнесу

Бизнес сам это купит когда монолит станет сложно поддерживать. Примерно в это же время станет ясно как его распиливать. Если вам хочется распилить, а бизнес не покупает — бизнес всегда прав (как в «клиент всегда прав»)

Так нужны ли эти микросервисы вообще? Зачем (ну кроме горизонтального маштабирования) он онадо, если ваш монолит и так модульный, с доменами и т.д.? Чтобы команду девопсов кормить (или в худшем случае девам жизнь усложнить)?
Я не эксперт в микросервисах. Но из имеющихся знаний могу сказать, что как минимум для независимого развертывания отдельных частей системы, повышения отказоустойчивости всей системы (если выйдет из строя один сервис, остальные будут работать и клиенты могут даже не заметить этого), ну и масштабирование команд разработчиков (я бы посмотрел как над одним монолитом будут работать 50-100+ человек). Но опять же, ни кто не говорит все бросать и переходить на микросервисы. Уже много раз говорили, что они подходят только под большие продукты, которые уже созрели и с ними сложно работать как с монолитами. Если это стартап, то даже не стоит пробовать, тут как раз подойдет модульный монолит.
Мне кажется, что перечисленные приемы можно использовать не только для перехода на микросервисы, но и для постепенного переноса функционала в новую версию приложения, или даже новые реализации функций в пределах приложения.
После того как существующая кодовая база начала обретать смысл, стоит подумать о следующем очевидном шаге — взять только что выявленные стыки и начать извлекать их как отдельные модули, превращая монолит в модульный монолит.


Что такое «стык»?
В данном контексте имелось ввиду границы ограниченных контекстов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории