[eropple]

I would suggest that there is a nontrivial difference between a service-oriented architecture and microservices, and there can often be a lot wrong with the latter when misapplied. In smaller teams, thinking in terms of a service-oriented architecture (I prefer "product-oriented architecture", where something like a shared auth service is a product making semi-formal or formal contractual guarantees to its customers, internal or otherwise, at a business rather than a code level) tends to break up into larger pieces of functionality. You are still paying a cost for doing so, but I have found most clients to be more receptive and better able to manage, say, three of them, rather than a dozen or more.

Most teams don't have the problem that microservices actually exist to solve: a fractured org chart. Because that's when you want and need microservices--when your org chart's reporting chains are separated to the point where you need to separate functionality for human and political reasons, so as to avoid having one set of interests stomp on another. There's a geometric cost to any services; generally speaking one should be sure that the carried organizational and technical load of adding another (in the microservice-swarm pattern this load is smaller on margin but heavier in frequency, and it adds up) has positive ROI.