>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.
When they rolled out clear case in my team at IBM, I quit a few weeks later.
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.
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.