[twotwotwo]

Yao Yu made some observations in her (excellent) talk about caching at Twitter over the years (https://youtu.be/rP9EKvWt0zo) that stuck with me: having a bunch of services doesn't itself isolate problems within one service. Twitter's cache service had to deal with clients rampaging to all load the same key zillions of times, for example.

The impression that gives me is that some of the gain from microservices might be from doing all of the things we're used to doing at service boundaries: documenting APIs, sanity-checking requests, logging, monitoring availability/resource usage/other metrics, etc.--the same sort of things any public Web service does knowing it's going to have to deal with funny clients, rising and falling load, and so on.

If all of the stuff it would take to properly maintain another usable customer-facing service sounds too expensive, that may be a sign that this isn't the place to split off a service. But if you find yourself wishing for separate monitoring, a cleaner API, etc. around some part of your system, it becomes more interesting to separate.

(I can also buy that some folks can see organizational benefits, or benefits from isolating hardware or making operations async, but separate ideas.)

[tracker1]

There's also load... If you have a specific service that needs more resources, you can allocate more instances of that service on more machines.

[twotwotwo]

(Yep, totally agree--was trying to get at how there could be other benefits in the last parenthetical comment. The extra process we do at service boundaries just stood out at me from the caching talk.)