I have a problem. Let's use Microservices! Now I have 13 distributed problems.
Dividing your system into encapsulated, cohesive, and decoupled components is a good idea. It allows you to tackle different problems separately. But you can do that perfectly well in a monolithic deployment (see Fowler: Microservice Premium). After all, this is what OOP has been teaching for many decades! If you decide to turn your components into microservices, you do not gain any architectural advantage. You gain some flexibility regarding technology choice and possibly (but not necessarily!) some scalability. But you are guaranteed some headache stemming from (a) the distributed nature of the system, and (b) the communication between components. Choosing microservices means that you have other problems that are so pressing that you are willing to use microservices despite these problems.
If you are unable to design a monolith that is cleanly divided into components, you will also be unable to design a microservice system. In a monolithic code base, the pain will be fairly obvious. Ideally, the code will simply not compile if it is horribly broken. But with microservices, each service may be developed separately, possibly even in different languages. Any problems in the interaction of components will not become apparent until you integrate your components, and at that point it's already too late to fix the overall architecture.
The No 1 source of bugs is interface mismatch. There may be glaring mistakes like a missing parameter, or more subtle examples like forgetting to check an error code, or forgetting to check a precondition before calling a method. Static typing detects such problems as early as possible: in your IDE and in the compiler, before the code ever runs. Dynamic systems don't have this luxury. It won't blow up until that faulty code is executed.
The implications for microservices are terrifying. Microservices are inherently dynamic. Unless you move to a formal service description language, you can't verify any kind of correctness of your interface usage. you have to test, test, test! But tests are expensive and usually not exhaustive, which leaves the possibility that problems might still exist in production. When will that problem become apparent? Only when that faulty path is taken, at run time, in production. The notion that prod issues would lead to faster feedback is
hilariously dangerously wrong, unless you are amused by the possibility of data loss.