[buster]

There are many valid reasons (and many wrong reasons). I would say: If you have multiple stakeholders, evoling business needs and many ( > 10) developers, there might be a good reason to have independent deployable, testable and releaseable units. Having few developers with a well defined context working on multiple microservices is a pain, though.

Regarding "Everything else is just shifting complexity from software development to system maintenance.": This sounds reasonable if your software is actively developed. Development is expensive. It may very well be, that the costs of maintaining a distributed system is lower then the cost of developing a very large monolith with a large team. In the end, it depends.

[sazz]

"There might be a good reason to have independent deployable, testable and releaseable units"

Of course this is the bottom line. But everything you define in the sentence can be achieved with a proper pipeline and repository architecture based on a monolith as well. For example teams could use a branch setup where they own their own team branches capable of merging to master and deploying. Each team could then define their own testing strategy and Definition of Done on their "team master".

Having the ability to release independently is actually a social problem, not a technical one. But the symptom of that social misalignment often shows up as a technical problem (dropping release KPIs, etc.)

So changing from a monolith to microservice will most likely only fight the symptom, not the root cause.

[buster]

First, you offer technical solutions (pipelines, branching...).. The cost of having multiple teams branching and merging the same code base can be significant. It's often not as easy as you make it sound.

[sazz]

In the end it is exactly the same technical complexity, it is just shifting complexity from point to another.

A proper branching strategy is not a technical solution but a social alignment of people contributing to common product. And it doesn't matter if they are contributing on different repositories or on the different branches. The technical complexity of aligning interfaces is the same in both cases.

"It's often not as easy as you make it sound."

No, it's of course not easy. But the costs in splitting teams up into different repositories and aligning their interfaces is not easy either. My point is they are both the same - just expressed differently.