21–27 of 27 posts
"There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton https://martinfowler.com/bliki/TwoHardThings.html
There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
Earlier quoted context omitted.
Yes, I agree with that. Containers though, as far as some of the advantages; we have been using chroots for deployment since the early 2000s which is not the same but deployment/compatibility wise it was pretty good. It allows you to have the same small Linux image and deployment everywhere as well and you could move most zipped images from machine to machine with vastly different kernels. I still use chroots now on…
I used chroots, too, and it was useful but much harder to maintain than a container. Automation wasn't impossible, of course, but that was also complicated by concerns about bloating each chroot with copies of all of the system libraries & config files. I used PHP in that era. It could be faster but then you're in the classic developer productivity tradeoff between, say, hand-coded SQL calls versus using an ORM, etc.…
And maybe the rails perf was comparable to the larger pho frameworks in some cases, but php was really much easier to scale in our experience. We hosted millions of sites and the python/ruby ones were generally dramas when they got serious (for that time) traffic.
"There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton https://martinfowler.com/bliki/TwoHardThings.html
There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
> There are only three hard things in Computer Science: cache invalidation and naming things.
Earlier quoted context omitted.
I used chroots, too, and it was useful but much harder to maintain than a container. Automation wasn't impossible, of course, but that was also complicated by concerns about bloating each chroot with copies of all of the system libraries & config files. I used PHP in that era. It could be faster but then you're in the classic developer productivity tradeoff between, say, hand-coded SQL calls versus using an ORM, etc.…
Hahah yeah ; I did a lot of hosting then and everyone insisted on register_globals. I still run stuff for clients that depends on it to this day. And maybe the rails perf was comparable to the larger pho frameworks in some cases, but php was really much easier to scale in our experience. We hosted millions of sites and the python/ruby ones were generally dramas when they got serious (for that time) traffic.
What I find most interesting in this is the pseudo detective story of hunting down disappearing post-mortem and "lessons learned" documentation. Optimistically we'd hope that perhaps the older systems no longer reflect the existing systems in any meaningful way (possibly as the org structures and/or software stacks shift and change) and they're no longer relevant. I'd imagine most lost knowledge is not an explicit de…
As you say, the default tendency in many companies when failures occur is information-loss. That can be attributed to using too many communication tools, cultural expectations that problems should be hidden, silo'd or disparate documentation stores, or lack of process.
Intentional, open, thorough and replicated note-taking with cross-references before, during and after incidents can create radically different environments which allow for querying, recovery and improvement regardless of failure mode(s). Kudos to Dan for moving in that direction with these writeups (and to you for raising the subtext).