In recent years I've seen several startups go for a microservices-first approach. This is my two cents, distilled from watching those projects unfold.
If you’re Netflix or Amazon, one of your big problems will be coordinating different teams and projects. Sooner or later, you'll hit a situation where you need to coordinate the release dates of five different projects to get something major launched.
On that day, you're hosed.
One sub-project will always slip, so five teams sit near-idle for a month, burning time and money. Fast forward a year or two and you wake up to six-month drop-dead release cycle with a month-five code-freeze and a month-four crunch window. It’s horrible. And it never improves, because coordinating groups of people is hard. [Citation: Theresa May, 2016-2018]
If you’re in that situation, microservices are brilliant. They allow you to turn a human-coordination problem into a system-coordination problem. System coordination is still hard - supporting multiple versions, dealing with concurrency issues, building distributed, fault-tolerant systems - these are all properly, Computer Science hard. But they're tractable. Computer concurrency problems are a pain, but you can solve them. People concurrency problems are the nightmare scenario second only to herd-of-cats concurrency problems.
Microservices turn people coordination problems into software coordination problems. Microservices are the way out of a quagmire.
But what if you don’t have those problems? What if you only have twenty-odd developers, and you can coordinate just by talking to them? What if your project coordination problems boil down to, "asking Andy and Catherine if they're ready?" Then by choosing microservices you've created API versioning problems, created concurrency problems and created distributed, fault-tolerant problems, all for no benefit.
In the absence of the relevant people problems, microservices create software problems. Microservices are the way into a quagmire.
Update (1/4/22) Lately I've been exposed to a different style of building microservices which I'm still thinking through. The first approach - the one I spoke about in this post - looks a lot like a zoomed-out version of Object Orientation, in which you build systems that are independent, stateful islands talking to each other through messages.
The second approach to microservices looks a lot like a zoomed-out version of Functional Programming, which you build systems that look like streams of immutable data, with independent transformations on those streams. I'm still thinking through the implications, and it deserves a its own new blog post, but for now I've put some of my thinking into this talk: Side Effects Are The Complexity Iceberg.