казинакзабыл никРечь вообще не об этом, при планировании\спринтах монолита невозможно всунуть фичу очень быстро, несмотря на то что она бизнесу нужна еще вчера. Потому что надо провести регрессию, убедиться что другие истории\фиксы ничего не ломают и тд и тп, это долгий процесс. В случае с микросервисами(хотя у меня тоже двоякое к ним отношение) это возможно и цикл между запросили фичу\получили короткий, что бизнесу очень нравится, а то что думают админы или девелоперы по большому счету сейлсам все равно
тот факт что добавление новой фичи или какой нить багфикс несет с собой риск того, что можно сломать что то еще, говорит о том, что проект хреновый. Слишком связный или есть библиотеки, которые используются везде. Такой проект и на микросервисы разделить непросто, т.к. придется дублировать библиотеки во всех сервисах, либо организовывать тесное общение между сервисами.

В общем если проект такой, что там километры переплетающегося г-кода, и толпа обезьянко-кодеров в команде, то ни микросервисы, ни что либо другое не помогут.

Но это вопрос организации и кадров. Здесь это офтоп.

— Traps on the Path to Microservices, George Woskob, ThoughtWorks

Самый честный доклад про микросервисы, который я когда-либо слышал! Товарищ из ThoughtWorks (той самой ThoughtWorks, в которой работает Мартин Фаулер ) вначале похвастался тем, что распилил уже не один монолит и что знает всё про микросервисы. А потом прошёлся по «болевым точкам» перехода от монолита к микросервисам. Вкратце доклад можно сформулировать так: «Они обещали нам рай с микросервисами, а в реальности чаще всего получается такой адище, что лучше уж оставаться на монолите» . Например, как-то так, по мнению автора, выглядит типичный процесс перехода на микросервисы:



https://habr.com/company/badoo/blog/358814/


тот факт что добавление новой фичи или какой нить багфикс несет с собой риск того, что можно сломать что то еще, говорит о том, что проект хреновый.
В качестве примера:
В каждой системе чуть сложней "лайканья" котиков необходимо разграничение доступов, а это сервер(пусть cluster) выполняющий процессы authentication/authorization. Пусть это будет microservice+load balancing/cluster.
И вот обнаружилась critical spectre - что дальше? проект хреновый? хипстеры в панике бегут искать новое место работы, где еще не хреново?

Слишком связный или есть библиотеки, которые используются везде. Такой проект и на микросервисы разделить непросто, т.к. придется дублировать библиотеки во всех сервисах, либо организовывать тесное общение между сервисами.
Да мир несовершенен, сервисы между собой общаются. Кто-то слишком, кто-то не слишком. Ещё к примеру логируют свои действия(при возможности при помощи единой библиотеки - чтобы в случае изменения формата не изменять в 100-500 местах), и часто складывают в единое хранилище для анализа и разборов "кто, где насрал", в едином формате, а ещё кто-то их заставляет отчитыватся "Online" для выстраивания и отслеживания бизнес процессов+мониторинга - вообще жуть.
Слишком связный или есть библиотеки --> Это примерно, как отличие спекулянта от инвестора/порнографии от проституции.
Сточки зрения банка у него много-много микросевисов, что зрения ЦБ каждый банк это все лишь микросервис.

В общем если проект такой, что там километры переплетающегося г-кода, и толпа обезьянко-кодеров в команде, то ни микросервисы, ни что либо другое не помогут.

Но это вопрос организации и кадров. Здесь это офтоп.

Не сотвори себе кумира и всякаго подобия, елика на небеси горе, и елика на земли низу, и елика в водах под землею: да не поклонишися им, ни послужиши им.
(даже в компании, где работает кумир - ThoughtWorks есть люди готовые думать головой, а не ж.)