> “One of the most common misconceptions about microservices is that they solve a technology problem,” says Johnston. “But really they solve a business or organ

> “One of the most common misconceptions about microservices is that they solve a technology problem,” says Johnston. “But really they solve a business or organization scalability problem.” I disagree. Service oriented architecture (note I don't say microservices, because I think that often goes too far) does solve technical problems. But they are problems that articles like this often ignore (maybe the authors have some misconceptions about microservices themselves). For me the main benefit of seperate services isn't about organization of code or teams, it is about isolation. The technical problems I think service seperation solves are: How do I ensure that a security vulnerability in X doesn't compromise Y (least privilege)? How do I minimize the blast radius if an unusual request or traffic patternconsumes an unexpected amount of resources (related to above, but doesn't necessarily need to be malicious)? How do I deploy a change to X without having to rebuild and retest everything else? How do I give a group of people access to manage X without giving them permissions for Y. How do I optimize usage of some resources? (Note: multiple services have overhead, so for this to apply, you need to have enough scale that the benefits of fine-grained scaling and rightsizing of individual services outweighs the costs, but contrary to some comments you don't have to be quite as big as google for it to matter). For some of these,"microservices" are not the only solution, and depending on your exact situation it may or may not be the best solution. The important thing is to understand what specific problems you are trying to solve, why, and what the tradeoffs are.