Well I think that's one of the benefits of microservices actually.
Cut out all the services that have deep tribal knowledge from people let go and replace them with new services if the service is actually important or just remove it altogether.
What I wonder is how often the "remove" operation happens. I'd wager it's more likely there are many services doing variations of the same thing, but existing ones are hard to kill because there is a web of dependencies.
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.
The cloud and open source world, especially in the infrastructure space has moved incredibly fast in the past five years. It's certainly possible that an in house microservice can now be replaced with one of the latest AWS services or even some of the latest apache OSS + a few lines of yaml/config.
That doesn't mean it never provided value, just that there are now better alternatives.
> 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?
If they're doing microservices well then these services are probably instrumented in a way that makes it trivial to observe and understand the callers' expectations.
Uber's github shows lots of work on opentracing, so if that's widely deployed then the remove operation is a straightforward.
Cut out all the services that have deep tribal knowledge from people let go and replace them with new services if the service is actually important or just remove it altogether.