I'm most curious how 1000 services fit in 8000 repos.
(Maybe it's the same way that 40 cities fit in 70 countries.)
---
FYI, with Git, the "repo too big" problem has a lot of solutions.
Grafts (shallow commits) for long histories, large file storage (LFS) for binaries, and in extreme cases filter-branch.
Yes, when you hit Google scale is it possible to write enough source code to not fit on disk. But Uber isn't Google scale. Maybe Uber can't fit code into one repo. But ten repos should be fine.
The 40 is probably a typo, the cities number is closer to 400.
I don't think the microservices is about repo too big in a technical sense. The problem is when you have 100s of engineers working on a single repo, just merging changes or building , testing etc. will take all day. Microservices are more a solution to scaling engineering teams with a lot of people because they can work independently rather than a technical scaling thing.
(Maybe it's the same way that 40 cities fit in 70 countries.)
---
FYI, with Git, the "repo too big" problem has a lot of solutions.
Grafts (shallow commits) for long histories, large file storage (LFS) for binaries, and in extreme cases filter-branch.
Yes, when you hit Google scale is it possible to write enough source code to not fit on disk. But Uber isn't Google scale. Maybe Uber can't fit code into one repo. But ten repos should be fine.