5 ms·
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 (technica
by Psyonic 4y ago
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.
- steve_adams_86 4y agoI 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.
- schrodinger 4y agoIt's really easy to innocently slip into a culture of "new project? new service!" and at Uber's scale, that could easily hit 10k.
- steve_adams_86 4y agoYeah, I’m starting to realize my experience in software is even smaller scale than I thought.
- tootie 4y agoRepos 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.