The author correctly identifies the problem as part technical, part people. My shot-in-the-dark estimation is probably 70% of teams doing microservices do it to

The author correctly identifies the problem as part technical, part people. My shot-in-the-dark estimation is probably 70% of teams doing microservices do it to solve the people problem before (if ever) they need it to solve the technical problem. Technical solutions are _usually_ bad solutions for people problems, and architectural patterns are probably even worse solutions at solving the problem of human collaboration. It doesn't help that microservices are mostly a better-sounding name for "SOA, but smaller", that has grown in prominence mostly to sell you hosting for your very many microservices. Microservices takes one of the hardest and most important parts of of SOA (service boundaries) and replaces it with...smaller. Glad to see someone at a larger company publishing about this.