[guhcampos]

No, not at all. I see why you think of it as a curse, I don't enjoy it as a resulta, but it's an observation of a pervasive pattern, not a design decision. It emerges from the way humans communicate and organize themselves.

You can either fight it agressivelly and try to minimize it, or you can "embrqce" it and try to adapt. I could force it into a disability analogy:

if you become suddenly deaf, you can agressivelly try to reverse it by all medical means possible, and you might succeed. Or you might not, then it would be better for you to accept the fact you are deaf and design your life around this disability as a means to adapt yourself to it.

That's how I see microsservices, too: accepting that large enough organizations cannot communicate as effectivelly and efficiently as small ones, therefore designing systems to minimize the impacts of these communication failures.

[hmeh]

The difference, though, is that microservices was more about the focus on the micro. That was, small things. Not per-team things. It was about trying to break things down into the smallest possible piece (while simultaneously ignoring software design IMO). A single team could end up with 5 microservices. A single microservice may not need to be touched after it's deployed. It's true that this can facilitate multiple teams, and you say this when people emphasized the technology soup approach to microservices: finally, you can combine Go, Rust, Java, Ruby, TypeScript, and even COBOL!

By the way, the entire premise that you should organize your software based on the way teams are organized is the flawed thing. Natural designs emerge when designing software. If you must have multiple teams, it may make sense to distribute some of those partitions that emerge across those teams. Or it may not. What absolutely does not make sense is creating partitions to account for your multiple teams. That's design-by-making-stuff-up and it's as doomed to failure as the REST-based-microservices fad.