The more/smaller microservices you have, the more frequently your APIs must change. It’s more fruitful to recognize that this is a dimension of freedom rather than a binary decision.

I mean I recommend that you don't go micro right away. But a few well-placed service boundaries that align with your eng org chart pay dividends and help build discipline and rigor. Even if the services are all running on the same box to start and just IPCing over localhost or w/e. I prefer my teams build habits while it's easy and fun rather than once the monolith gets unwieldy and drawing boundaries becomes painful.

You avoid a lot of things in a monolith. But normal services mapped to your org chart tend to be pretty nice. I hate how people spam "micro" service talk as if that's the end game for putting a physical boundary between software.