"Using microservices poorly" -- this comes up a lot when I discuss microservices with people who believe in them. I think it comes close to the True Scotsman fa

"Using microservices poorly" -- this comes up a lot when I discuss microservices with people who believe in them. I think it comes close to the True Scotsman fallacy -- if microservices ended up causing a mess, the explanation is always that one wasn't using microservices "properly". 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.