I can't believe this made it out of any planning meetings.

Engineer 1: "We'll have one repo per downstream service."

Engineer 2: "But we have hundreds of those, so now we have to manage hundreds of github repos???"

Anyone sane: "That doesn't sound right, we should rethink this..."

Probably because when they suggested it they had about 10, growing by 1 per 6 months. Then a few years later they end up with 100, growing by a few a month, and need to rethink.

I though this was an honest and interesting look at a decision which in retrospect was a bad idea. Hopefully it'll stop some other people making similar mistakes (too many repos, too many services, fast changing libraries shared between many services, etc...).

It'd be better if it wasn't framed as having found that the one true way is the monolith, but there are some lessons here for most devs.

I've seen worse. And I wished that I was kidding.

Storytime?

Every microservice on its own little cluster of VMs for HA and performance...

A couple of hundred VMs is nothing in a scenario like that. Good luck trying to debug anything.

That's basically how microservices are operated on orchestrators like Kubernetes—just substitute "container" for "VM", which is a mostly-academic difference from the perspective of your application. Operations tooling—distributed tracing, monitoring, logging...—is essential.