Mostly agree that this aged gracefully, with the exception of the section on Concurrency which states that you shouldn’t scale out by adding threads but should use multiple OS processes instead even on one machine. I feel like that was one place where Heroku’s background doing mostly Ruby apps (in a time where Ruby couldn’t safely use threads) leaked out into what was supposed to be language-agnostic advice.
This is going with the lowest-common-denominator; absolutely awful advice for anyone on the JVM, BEAM, or other runtimes which handle concurrency gracefully.
Edit: it looks like the wording for this actually changed since it was originally published to make it less clear. Now it seems to just be saying you need to be able to split it into multiple processes when it outgrows a single machine, which … I dunno. The point of share-nothing was already made very clearly in other sections so this doesn’t really seem to be meaningful advice, but hey, meaningless advice is better than bad advice.
Since developers have coalesced around git, roughly the past decade, things have changed rapidly. Before that, source control was really piecemeal and not everyone used it. I’ve seen “deployments” happen by FTPing files to production, or even god-forbid live edits.
If you were insulated from this, count yourself lucky.
I think this article would be significantly improved if the author summarized each factor before their discussion. I’ve read the original thing before but I surely didn’t memorize it, ya know?
Mostly agree that this aged gracefully, with the exception of the section on Concurrency which states that you shouldn’t scale out by adding threads but should use multiple OS processes instead even on one machine. I feel like that was one place where Heroku’s background doing mostly Ruby apps (in a time where Ruby couldn’t safely use threads) leaked out into what was supposed to be language-agnostic advice.
This is going with the lowest-common-denominator; absolutely awful advice for anyone on the JVM, BEAM, or other runtimes which handle concurrency gracefully.
Edit: it looks like the wording for this actually changed since it was originally published to make it less clear. Now it seems to just be saying you need to be able to split it into multiple processes when it outgrows a single machine, which … I dunno. The point of share-nothing was already made very clearly in other sections so this doesn’t really seem to be meaningful advice, but hey, meaningless advice is better than bad advice.
Uhh, what? Version control was in widespread use long before git, much less GitHub
Since developers have coalesced around git, roughly the past decade, things have changed rapidly. Before that, source control was really piecemeal and not everyone used it. I’ve seen “deployments” happen by FTPing files to production, or even god-forbid live edits.
If you were insulated from this, count yourself lucky.
Version control was widely used, but not widely enough for it to be a safe assumption that every project would use it.
I think this article would be significantly improved if the author summarized each factor before their discussion. I’ve read the original thing before but I surely didn’t memorize it, ya know?
Every image has a small caption. It contains what seems to be the original factor, such as “One codebase tracked in revision control, many deploys”.
Wow I completely missed those and I read the whole dang thing.