[walrus1066]

"10 teams of 3 each owning their own little slice of the pie sounds like an organizational nightmare; mostly, you can't keep each team fully occupied with just that one service, that's not how it works. And any task that touches more than one microservice will involve a lot of overhead with teams coordinating."

I guess that's where the critical challenge lies. You'd better be damn sure you know your business domain better than the business itself! So you can lay down the right boundaries, contracts & responsibilities for your services.

Once your service boundaries are laid down, they're very hard to change

It takes just one cross-cutting requirement change to tank your architecture and turn it into a distributed ball of mud!

[s_kilk]

Which has to stand as a damning indictment of the one-service-per-team model, surely?

Something so inflexible can't survive contact with reality (for very long).

At work we run 20-something microservices with a team of 14 engineers, and there's no siloing. If we need to add a feature that touches three services then the devs just touch the three services and orchestrate the deployments correctly. Devs wander between services depending on the needs of the project/product, not based on an arbitrary division.