Hacker News Reader

Comment by tiborsaas | Hacker News Reader

Cab service on a planetary scale :) They have 2000 engineers, 800 microservices and 8000 GIT repositories. Does it still seem trivial to you?

EDIT: to downvoters: why shoot the messenger? :)

View on HN

Sounds like they should sit down and re-think why they need one service for every two engineers (!), and ten repos per service (!!).

A leading example of overfragmentation.

On-call shifts are going to be interesting with an average of 2.5 engineers per service, not to mention handling people switching teams or leaving the company.

> Sounds like they should sit down and re-think why they need one service for every two engineers (!)

They did that; the reason is job security.

Maybe they prefer repos to branches?

I'm curious how a company ends up with 10 git repositories per microservice, and 4 repositories per engineer?

That's just a manifestation of Conway's Law [1].

[1] https://en.wikipedia.org/wiki/Conway's_law

Taken in a healthy organization, Conway's Law is not a bad thing. It is really just more of an observation. So... taken to this example, it sounds like the company is a confusing mess of people trying to figure out who they need to coordinate with to make something happen.

> It is really just more of an observation.

Or maybe some instruction into how to assemble the organization.

True. I was using it as an argument to adjust the system architecture, as well. My argument was it didn't matter really which changed to get things into alignment, but that having them be different was a bit of a concern.

4 repositories per engineer

Is that strange? I've got 6 repos at work for various utilities and "personal" projects I'm working on in addition to the 4 repos for team wide projects.

I have over 3 dozen private Git repos for personal amusement or utility projects for stuff that professional consumer software doesn't work as well as what I want. Then I have almost at least 10 repos on GutHub (not this userid). At my last work, 9 month contract, I had 4 I think, aside from our main team repos just to manage personal info documents, my bin folder, etc. It's easy for one developer to have several. On my Linodes I keep /etc in its own repo as well, and my VirtualBox and VMware VMs then inside those I keep several Git repos.

Edit: I remembered more personal projects, make that almost 3 dozen personal Git repos.

THE HN PC police are back, up to their old antics.

My guess (and it is just a guess) is that each of these services is made up of multiple even smaller libraries which are each being version controlled as a distinct entity. I'm not sure I could fully get behind working at that level of granularity, but it would explain how you end up with quite so many git repositories.

From what I understand, they split their microservices into logical packages and libraries, each of which have their own repo. Then some microservices have a separate repo to track configuration changes.

  10 git repositories per microservice

I'm reminded of http://danluu.com/monorepo/

I would bet that they have location data in git with each major market being it's own repo.

This leads to an interesting perspective, that there is a hard limit on how much traffic your services will ever have to handle, and that limit is probably a constant expression on the planet's population.

But I can't imagine how you could possibly need 8000 git repositories unless you're massively over engineering your problem. Project structure tends to reflect the organizations that build them.

This seems almost the exact opposite of what I've heard of Facebook (i.e.: they have a massive repository).

Sounds like they have 2000 very individualistic engineers with that level of insanity.

2000 engineers sounds like overkill for a mobile app

Reply on news.ycombinator.com