(Of course, there are several other ways to get 100 engineers to have the output of 10; but I think microservices makes the engineers a lot less frustrated when it happens compared to more traditional alternatives)
To your original point though, correlation doesn't equal causation, and just because you could abuse a technique to placate your wrong-sized org using this technique doesn't mean that it's the purpose of said technique.
I could say the same of a monolith -- if it is a big ball of mud then it is not a Proper Monolith ...
Granted, my only experience with microservices was a ball of mud mess microservices. I am sure we will both agree they were NOT doing microservices correctly -- BUT -- they did not know that going in did they?
If microservices is defined by definition to only be about the successsful applications of the technique, then it is not very helpful for those choosing architecture for a new system..
Re shifting services to other teams:
We have a medium-sized-service architecture, not monolith nor microservice. One or two services per team mostly.
By far, the hardest part of onboarding and doing development is learning the business domain and have people understand WHAT to do, why to do it, etc. -- the HOW is usually simple.
Code usually covers only the HOW part. Just shipping parts of what we do to another team and expect them to be on top of things quickly doesn't seem realistic regardless of the size of services..
Teams are homes for business and domain knowledge first. A home for the code is just a byproduct.
Seems like this falls under "doing work", not creating output. You're doing a lot of work.
> The monolith doesn't work well in multi-team setups..
There are other ways of splitting work between multiple people and teams without introducing a network call.
Can you explain this reasoning?
With microservices, you make 10x as much work in such a way that the work seems meaningful and is perhaps even fullfilling. It takes some effort to see that the complexity you are solving day to day is accidental complexity, not essential complexity.
