The part I love about microservices, and something that I think doesn&#x27;t get enough attention, is that is strongly enforces separation of concerns across micro-projects.  API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them.  Essentially, you are moving some of the software &#x27;best-practices&#x27; up a level form modules to applications themselves.  This means that you don&#x27;t need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road.  Got a service that was rushed out the door and isn&#x27;t maintainable anymore?  Rewrite it!  2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application.<p>And that is the other thing that I think microservices are great at:  They are pragmatically easier to change.  Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that.  Microservices are easy to understand because they are small, discrete systems with well understood interface contracts.  Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.