Hacker News Reader

Uber was the opposite. In ~2017 after years of hyper growth they had over 10,000 repos supporting nearly as many micro-services. The move to monorepos (technically two, one for jvm stuff, one for go) came as a solution to the maintenance issues of this sprawl. I was there when a mandate came down to move your service into the monorepo.

View on HN

I don’t understand how it’s possible to have close to 10,000 services. I worked on a project with 17 and found that to be very awkward at times (local development with k8s didn’t seem to be a solved problem, and we depended heavily on complex tests and blue/green deploys to be sure changes actually worked in production). But nearly 10,000 is insane.

How do you orchestrate that? I guess this is the kind of situation where you really do need container orchestration.

It's really easy to innocently slip into a culture of "new project? new service!" and at Uber's scale, that could easily hit 10k.

Yeah, I’m starting to realize my experience in software is even smaller scale than I thought.

Repos aren't one-to-one with running services. Lots of these could easily be bundled as modules to be included at build-time. A lot of them could also just be API services that provide a contract via REST or whatever. If you have enough internal users, you just have to maintain an SLA comparable to a public API.

Reply on news.ycombinator.com