I don't like correcting with "well, actually", however, I have to say that the author of the book "Building Microservices" in his first few chapters (in particular: Chapter 3: Premature Decomposition) warns against using microservices with new apps, especially if you are new to the domain. He claims that they are actually easier to use when you have to refactor a large monolith, and that normally you shouldn't start with microservices unless you know what you are doing - therefore my criticism towards the article which starts with a pre optimization (split one service in 12), which seems to be a common, yet arguable practice.

This has not been my experience. I've seen a few projects where microservices had been added from the start because it's the thing to do and, in all cases, it didn't work well. It's extremely difficult to split in microservices if you do not have a clear big picture of your projects functions and coupling. And, in most cases, in new projects, you don't have that big picture.

Microservices also make it much harder to refactor the code which you often need to do in the early stage of a project.