Comment by ErroneousBosh
6 hours ago
> I'm a broken record on how important I think this document is, and that it's hard to appreciate it until you've had extended experience with complex systems actually failing.
If you want a bit of cheese to go with that wine, this article pairs nicely with The Grug-Brained Developer: https://grugbrain.dev/
I am also a broken record about Grug-brainedness, but I don't need to be so repetitive about it because so many other people are too.
My Grug-brained hill to die on is that there are many pieces of technology like the LM741 opamp, the Rover V8, Morris A-series and Peugeot XUD engines, and a big SQL database running on a thumping great Unix box, that have remained essentially unchanged for decades, worked well when they were new, and are still a perfectly good solution today for so much of what you want to do.
You know what they have in common? A lack of complexity. Lovely simple technology, fix it with a hammer. Drive it to the moon and back. Drive it across the desert. Bring tools though!
All things equal you're always better off ruthlessly killing complexity. Cook (I know you're not rebutting him) is focused on the problem of unavoidably complex systems. A big server running a single instance of Postgres is great, and you should absolutely use that architecture if you can. But real-world constraints can break the architecture: need it running in multiple locations, with a single global view, with strictly bounded propagation times (for instance: because you're running a routing protocol): it's still just a database problem, but now it's a much more complex one.
And then, naturally, you can get complexity just by building stuff on top of that big database server, and other things that depend on those things.