Don't be fooled into believing that microservices are popular based on technical merit. As the parent noted, this will just make things harder by trying to micro-ize a startup. Microservices are a thing primarily for their political convenience and dynamic, and they're just dressed up as a technical thing.
[Sideline: most of our technical fads are this way. Err on the side of "letting developers feel important and special while requiring as little effort as possible". Cloud servers are this way because it makes Unix greybeards transparent, and the brogrammer won't have to feel inadequate next to him/her, OR worry about esoteric command-line incantations. Document databases are this way for the same reasons, but replace esoteric command-line incantations with esoteric SQL aggregates (or any useful schema development at all, actually) and greybeards with DBAs. Rinse and repeat for every major development fad.]
Microservices are popular due to Conway's Law [0]. They give an out to people who would rather avoid the difficulties of interfacing, deliberating, and collaborating with other people in their organization. They don't have to decide on a common language, they don't have to decide on a common style, they don't have to do anything; they can go run amok, treating the company codebase as their personal playground, under cover of "super cool new-wavy best practices". "Google is doing it. You want to be like Google, right?"
There are potential good designs that would qualify as "microservice architectures", but I've seen them only rarely. What I see more often is what I like to call "brittle-services": dozens of tiny, fragile, interdependent units that are virtually impossible to debug, instrument, or reason about cohesively.
At $DAY_JOB, we have tons of these; if one service starts to slack off, there is a giant waterfall -- ahem -- of failures that cascades across everything else. The software has been structured this way for purely political reasons, even though no one would be willing to admit it.
Like everything else important, good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Unfortunately for the hoi polloi, it can't be generalized into a formula or paradigm like "use microservices", but it seems in any field, there are many posers eager to try.