https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580 feels broadly correct, but has some epicycles. SOA vs microservices is a spectrum, not black and white. Here's a cleaner way I think about things.

Programmer building simple, low-maintenance programs that reward curiosity about their internals. http://akkartik.name/about

Among other things, this answers how much utilization to aim for. Every service boundary is a place to introduce slack. If a single team owns too many (>10) tiny services, you get clusters running at 5% utilization. If too many teams share a single service monolith, everyone moves slower.

Splitting and merging service boundaries as orgs reorg is the critical skill. Splitting/merging services in unanticipated ways is why we need tests. Tech debt = software map lags the people territory.

It needs to be somebody's job (the CTO's?) to obsessively focus on this one metric, to adjust everything through this lens. The CEO/business has found product-market fit, a customer, a goal worth of an organization. The tech org executes toward the goal. The CTO's job is to not fuck up the org.

soapbox

For example, hiring. A team deploying a service splits into 2 = ok. 10 teams shipping a shared monolith = none of them gets to hire until some new service boundaries are drawn up. People who talk together should ship together, to within an order of magnitude.

</soapbox>

The essential software question of the last 50 years: how to split up the tech parts to minimize communication between people.

Teams that talk frequently among themselves should deploy together. Teams that don't need a service boundary so they can deploy separately.