1. 14
  1. 7

    It was last updated in 2017, but it is really from 2011.

    1. 1

      How can you tell? archive.org? I see the previous submission to lobste.rs is from 2012.

      edit: the Lobste.rs submission guidelines say:

      When the story being submitted is more than a year or so old, please add the year the story was written to the post title in parentheses.

      I am interpreting this to mean, when the story was updated. Because an update could replace much of the text. Is that the correct interpretation?

      1. 4

        I was hired by the author in 2011, can confirm that he had recently written it around that time.

        1. 3
      2. 3

        It’s really interesting to revisit this a decade later and see how many of these we take for granted nowadays. All of this predates the rise of Docker, but in a way it laid the groundwork for containers to take over. I guess that shouldn’t be too surprising since it was written by the CTO of Heroku, a company whose entire product was based on LXC containers before containers were cool.

        The only real mismatch I can spot is when it talks about dependencies; 12factor says you never depend on any system-level dependencies handled outside your language/runtime’s tools (the example it gives is curl) because access to those tools couldn’t (in 2011) be determined by the app’s configuration, which admittedly is one thing Docker makes relatively easy.

        1. 3

          One of the packaging issues at Heroku was including ImageMagick in the base image. Apps can use it without any explicit declaration or vendoring, and security patches would always mean rolling the dice on breaking apps. But for the most affected apps the patch broke a non-critical feature and prevented an RCE. Overall I thought it was a decent compromise. These days on dependencies I would say they can be declared almost all the way down to metal if you really want to.

          I’d say the issues of today aren’t declaring dependencies but having so many and keeping them updated. I’d introduce a corollary: dependencies not explicitly relied on should be aggressively upgraded or patched without delay or ceremony. No backlog items or prioritisation against new features - the work is simply done as a matter of course and isn’t questioned.

          1. 2

            Yeah, like … I’m super not a fan of Docker, but I have to say that things were a lot worse before it if you had significant dependencies written in C.

            The nixos approach is of course conceptually far more sound, but unfortunately worse is better, so we’re kind of stuck with Docker, but it hasn’t been so long that I’ve forgotten how we were legitimately worse off in the before days in many ways.

        Stories with similar links:

        1. The Twelve-Factor App via steveklabnik 9 years ago | 9 points | 1 comment