An issue I've seen happen is as the number of microservices grows, no one is keeping track of the service dependencies. So what happens is service A goes down, and then someone says "Service B is down too." and then people start thinking it's some wider outage (they always blame the network) but it turns out that Service B just depends on Service A, but it wasn't widely known.
The issue then becomes that teams don't have a good understanding of the expected impact due to an outage. They think microservices are helping to minimize the blast radius, but they really just don't know what the true blast radius is.
If a service A going down brings service B down, then microservices aren't divided right and/or too much data is being shared over the network rather than async transformed/copied. The only time this should matter is if there's a breaking change to the way services communicate which should be very well known, e.g. having to bump a protocol version number with downstream understanding before upstream.
Yeah, everyone knows this. The question as I understood it, was to ask what are some downsides to microservices. And that, to me, includes how they are implemented and managed in the real world, rather than some perfect hypothetical world where everyone did everything by the book.
There is no such hypothetical book. I've read many of them and collectively don't cover what you'll need to know or do. There's also very few things everyone knows about microservices. Choosing the right bounded contexts is the biggest knowledge gap and most examples talk about noun1 service and noun2 service.
Learning about microservices by reading books that distill it into abstract examples is like learning Haskell by reading about category theory. Maybe possible but challenging and not for everyone.
The issue then becomes that teams don't have a good understanding of the expected impact due to an outage. They think microservices are helping to minimize the blast radius, but they really just don't know what the true blast radius is.