4 ms·

The original "Monorepos please don't" article really just convinced me how great monorepos are when you aren't at scale. So you know, put your shit in a monorep

The original "Monorepos please don't" article really just convinced me how great monorepos are when you aren't at scale. So you know, put your shit in a monorepo, and then when it gets painful, break it out.

busterarm 8y ago
That process will take you 3-7 years, depending on how many resources you throw at it. Can your business survive 3-7 years of #seriouspain? This article hand-waves over many of the criticisms while ignoring a few cold realities. If you're following an infrastructure as code pattern and/or if you run bare metal, at some point you _WILL_ determine that some things are too sensitive to keep in the monorepo. Here is one of the places where coupling will screw you the hardest. Your lightweight production deployment repo will have a hard dependency on some nightmarish 35-40GB monorepo. Your collaboration tools like rietveld/gerrit will choke under the load and you will struggle to get big enough servers to maintain it. You'll do things like push to one target and pull from another. You'll deal with all sorts of transient failures trying to push or pull. Your CI/CD platform will start taking an eternity to do anything. Monorepos absolutely result in coupling and coupling is one of those nasty things that you don't realize how much of a problem it is until you're drowning. None of the above-mentioned complaints are theoretical. I've lived through them all.
- aidenn0 8y ago
  I imported a 20 year old SVN monorepo to git with 100s of thousands of commits and tens of thousands of branches/tags and it was under 10GB. Removing a few large .tgz files that were inadvertently committed brought it down to 5 GB. Linux has 25Mloc and ~800k commits; I think the pack is on the order of 2GB? I don't doubt that 40GB nightmarish monorepos exist, I'm just wondering how and why.
  - busterarm 8y ago
    Linux is a highly focussed project trying to accomplish a single thing well and with rigorous standards. If you have 100 developers working average US work schedules and making 5-10 commits per workday (debatable number, depends on culture, but i'm averaging between the "big" commit and lots of small commits), you're going to end up with 100k commits _per year_. And many large startups have a multiplier of that number of developers and they're much, much messier than kernel devs. Referencing the ideal case as counter-example is a bit silly.
    - aidenn0 8y ago
      So the nightmare monorepos are caused by unfocused teams trying to accomplish many different things poorly?

busterarm 8y ago

That process will take you 3-7 years, depending on how many resources you throw at it. Can your business survive 3-7 years of #seriouspain? This article hand-waves over many of the criticisms while ignoring a few cold realities. If you're following an infrastructure as code pattern and/or if you run bare metal, at some point you _WILL_ determine that some things are too sensitive to keep in the monorepo. Here is one of the places where coupling will screw you the hardest. Your lightweight production deployment repo will have a hard dependency on some nightmarish 35-40GB monorepo. Your collaboration tools like rietveld/gerrit will choke under the load and you will struggle to get big enough servers to maintain it. You'll do things like push to one target and pull from another. You'll deal with all sorts of transient failures trying to push or pull. Your CI/CD platform will start taking an eternity to do anything. Monorepos absolutely result in coupling and coupling is one of those nasty things that you don't realize how much of a problem it is until you're drowning. None of the above-mentioned complaints are theoretical. I've lived through them all.

aidenn0 8y ago
I imported a 20 year old SVN monorepo to git with 100s of thousands of commits and tens of thousands of branches/tags and it was under 10GB. Removing a few large .tgz files that were inadvertently committed brought it down to 5 GB. Linux has 25Mloc and ~800k commits; I think the pack is on the order of 2GB? I don't doubt that 40GB nightmarish monorepos exist, I'm just wondering how and why.
- busterarm 8y ago
  Linux is a highly focussed project trying to accomplish a single thing well and with rigorous standards. If you have 100 developers working average US work schedules and making 5-10 commits per workday (debatable number, depends on culture, but i'm averaging between the "big" commit and lots of small commits), you're going to end up with 100k commits _per year_. And many large startups have a multiplier of that number of developers and they're much, much messier than kernel devs. Referencing the ideal case as counter-example is a bit silly.
  - aidenn0 8y ago
    So the nightmare monorepos are caused by unfocused teams trying to accomplish many different things poorly?