I work in an IT department where we have many of the problems that microservices are supposed to solve. But we've been careful in trying to apply microservices. We have realized there are tradeoffs to consider that are often not discussed.
I recently wrote a blog post titled Microservices Beyond the Hype: What You Gain and What You Lose where I summarized the pros and cons of the new IT popstar, Mr. Microservice. An interesting consideration is that if you break a monolith into microservices, ceteris paribus the runtime autonomy of the solution will be negatively affected. But aren't microservices supposed to be autonomous? Well, the truth is that we need to employ techniques to improve autonomy in a microservices-based solution exactly to prevent autonomy issues inherent to microservices, as explained in the post.
You may look at the lists of pros or cons and disagree with one or another point. One reason for disagreement is that different people have characterized microservices in many different ways. Unfortunately we didn't have an objective, widely accepted definition from the beginning, and we still don't have one. In another blog post, I took a crack at Defining Microservices, not by introducing a new definition, but by sticking to the basics.