Are they going to regret having 4,000 micro services now?
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.
That doesn't mean it never provided value, just that there are now better alternatives.
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.
Uber's github shows lots of work on opentracing, so if that's widely deployed then the remove operation is a straightforward.
R = # of micro services / # of engineers
If R >= 1, this is potentially problematic and may indicate engineers being unable to work with the code of their peers. Operating in this regime would be viewed as risky. R can go to infinity very quickly if you go down this path without very deliberate planning, involving the consensus of both the entire management and engineering staffs.
If R < 1, you have more engineers than micro services. People share code bases and are not afraid of each other. This is probably a safe regime to operate in, even if you completely fuck up the intent of micro services.
I think R could also serve as an arbitrary bus impact scalar for the org chart.
R < 1 can mean that either the same functionality is getting reworked over and over, or people are breaking separation of concerns and concatenating unrelated stuff onto existing modules.
Ideally you want to be spotting the common patterns and replacing e.g. five 10k-line modules with one 10k-line module. But there's also an unfortunate tendency to favor consolidation into one 50k-line module. In that case they were separate for a good reason...