I've found that there are four main situations where separating functionality out in to a different service works: * That service would work well enough on its

I've found that there are four main situations where separating functionality out in to a different service works: * That service would work well enough on its own as a startup - it's internally complicated but isolated and requires a very simple abstraction (e.g. doing a postcode lookup service). * As a facade to create a clean interface to something that is not clean (e.g. a nice REST API that talks to a crazy weird industrial control system over a parallel port which only runs on windows). * The operational requirements of the code are entirely different (e.g. moving data processing from the webserver to a task server and feeding it via a queue). * As a means of linking components in a large scale system run by a large organization that has multiple teams that often write code in different languages and have real trouble coordinating with one another but are nonetheless overseen by a crazy smart architect. The latter was basically where Martin Fowler thought microservices worked well, and it probably did, but he kind of forgot that A) the absence of a crazy smart architect is more common than the presence and B) this was a hack which involved a shit ton of extra operational overhead that was only worth it because it solved a gnarly people problem. When startups of 7 people run more than 3 services I start looking for the microservice kool aid.