4 ms·

> This means, everytime you touch something under a repo, it affects everyone. This is horrible at scale. > This is a classic case of not understanding micro

> This means, everytime you touch something under a repo, it affects everyone. This is horrible at scale. > This is a classic case of not understanding micro services and trying to fit a problem around a tool. That much I agree with. TFA even acknowledges that, in the conclusion. Not in so many words, but they basically admit they did it wrong.

stickfigure 8y ago
>> This means, everytime you touch something under a repo, it affects everyone. >This is horrible at scale. I just want to reiterate this. In the early 2000s I worked in the online platform group at EA. The list of things done poorly there was long, but picture: * 40+ engineers * Monorepo with hundreds of thousands of classes; all code deployed to all servers. * Hundreds of different services running across thousands of servers. * Communication based on Java serialization, so all code had to be deployed to all servers at the same time. * Deployments (and thus downtime) sometimes lasted up to a hour. Worldwide audience; it was always in the middle of someone's day. * Rational Clearcase for version control. It took nearly an hour to sync to tip. Pretty much every morning you'd come in, spend an hour syncing, find that someone broke the build, hunt them down, and resync for another hour. Generally speaking the first few hours of every day were wasted for 40 engineers. This was a very poor platform. Sometimes I wonder how it's going there these days.
- alttab 8y ago
  The Java serialization downtime was sad, but I died when you said clear case. When they rolled out clear case in my team at IBM, I quit a few weeks later.
- eitally 8y ago
  Funny that it was this bad at an actual tech company. What you described is pretty common in normal big enterprise, though.
jdoliner 8y ago
> This is horrible at scale. This can work fine at scale, Google does it with however many tens of thousands of engineers they have these days. Having everything in a monorepo doesn't solve the communication problem, it doesn't prevent solving it either.
- eitally 8y ago
  Sort of. Google is also well known for having a dozen chat apps. What most people don't know is that there are also likely a dozen different libraries/utilities/interfaces performing near identical services just because an engineer or product team weren't 100% satisfied with what already existed. So yes, it's a monorep, but holy heck there's a lot of duplicative cruft.
- seabrookmx 8y ago
  > all code deployed to all servers This is the main point of the post. Google most certainly doesn't do this, even if they have all their code (or at least, all their private code) in one repo (piper).

stickfigure 8y ago

>> This means, everytime you touch something under a repo, it affects everyone. >This is horrible at scale. I just want to reiterate this. In the early 2000s I worked in the online platform group at EA. The list of things done poorly there was long, but picture: * 40+ engineers * Monorepo with hundreds of thousands of classes; all code deployed to all servers. * Hundreds of different services running across thousands of servers. * Communication based on Java serialization, so all code had to be deployed to all servers at the same time. * Deployments (and thus downtime) sometimes lasted up to a hour. Worldwide audience; it was always in the middle of someone's day. * Rational Clearcase for version control. It took nearly an hour to sync to tip. Pretty much every morning you'd come in, spend an hour syncing, find that someone broke the build, hunt them down, and resync for another hour. Generally speaking the first few hours of every day were wasted for 40 engineers. This was a very poor platform. Sometimes I wonder how it's going there these days.

alttab 8y ago
The Java serialization downtime was sad, but I died when you said clear case. When they rolled out clear case in my team at IBM, I quit a few weeks later.
eitally 8y ago
Funny that it was this bad at an actual tech company. What you described is pretty common in normal big enterprise, though.

jdoliner 8y ago

> This is horrible at scale. This can work fine at scale, Google does it with however many tens of thousands of engineers they have these days. Having everything in a monorepo doesn't solve the communication problem, it doesn't prevent solving it either.

eitally 8y ago
Sort of. Google is also well known for having a dozen chat apps. What most people don't know is that there are also likely a dozen different libraries/utilities/interfaces performing near identical services just because an engineer or product team weren't 100% satisfied with what already existed. So yes, it's a monorep, but holy heck there's a lot of duplicative cruft.
seabrookmx 8y ago
> all code deployed to all servers This is the main point of the post. Google most certainly doesn't do this, even if they have all their code (or at least, all their private code) in one repo (piper).