This can sometimes be worthwhile in a corporate environment even if technically it makes things harder, because it solves a major political / communication pro

This can sometimes be worthwhile in a corporate environment even if technically it makes things harder, because it solves a major political / communication problem. However, for the expense of dealing with the complications of an additional network boundary to worthwhile, some of the following must hold: * You need architect who has an overview of the whole system creates abstractions that make sense and puts the API boundaries in the correct place, avoiding the "tightly coupled microservices" antipattern. * You need good devops people who can track problems that span service boundaries. This is the one area where the company can't skimp (i.e. no outsourcing of this position). Without these people you get an epic political clusterfuck where everybody ends up blaming "the other" team for their problems. * The two services need to be built by two teams which, for whatever reason, cannot be relied upon to communicate or work effectively with one another (different orgs, different country, different company maybe). * The two teams possibly use different programming languages. I believe these reasons are probably the reason why it worked wonders for Martin Fowler. Then startups read his blog and decided that every team needed to build 15 microservices and the whole world went crazy (thanks Martin).