[capn_duck]

I've honestly never understood this argument. There's some changes that are intractable. Just being in a separate codebase doesn't mean you don't need to deal with it. Team A just modified their service to require a new field in a request? Now you just have Teams B-G having to play a card to update their corresponding code if they consume that service. And unless you have everything feature flagged across all teams in a consistent way, or are very careful about API versioning, you'll all need to release at the same time anyways. Nothing magical about microservices solves this, no?

[jacquesm]

If you suck at architecture, then yes, microservices won't solve that problem. But used properly, like with every other tool, this is one problem that can be solved this way.

The whole idea that you take a monolith and then explode it into 50 or even 100 pieces with all the added complexity that involves without thinking about it beforehand and aiming for specific goals is obviously broken and that's not what I'm advocating for. But when properly used you can design your services in such a way that those problems do not arise. Some eco-systems, notably Erlang have elevated this concept to first class status and from personal experience and looking at some companies that did it properly I can tell you that it works, and that it works very well.