Ah, the no true microservices idea of webservice architecture. If the idea is that you code to a webservice interface and then providers implement that interface, well, you're going to end up with the same problem, but with different interfaces. If the client specifies the interface using GraphQL or the like, that moves the problem from the incompatible interface to incompatible data naming. And so on. You need global coordination to untangle a mess of interrelated services, or you need continual migration work to adapt from one team's implementation to another.

No matter what you call it, if something can trivially be killed off, was it providing any real value in the first place? Dependencies aren't just things satisfied by linkers.

> If they're hard to kill because there are a web of dependencies then I would argue they are doing microservices wrong.

I call this the "You're doing it wrong" Theory of Architectural Deficiency: anything that appears to be a fundamental architectural issue is actually just you being an idiot.

For examples, see every discussion about REST ever.

I think that’s kind of the rub with microservices, it is actually a successful architecture when the vast majority of teams are unable to do it correctly?