Live data from Hacker News

The Twelve-Factor App (2011)

12factor.net

81–90 of 106 posts

Re: The Twelve-Factor App (2011)

#81
I feel there is a little misdirection in the 12F idea.

> The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

Not every landscape fits the WEB-LOGIC-mumble_db_mumble model. Sometimes your backing services are not Someone Else's Problem: maybe you need to curate them and deploy them with the rest of your 12F fleet (applying 12F where possible) but the realities are lots of handholdy things like state, schemas, migrations, and entropy in general.

Re: The Twelve-Factor App (2011)

#82
post #80
post #79

I really like this methodology and it still applies today across techs, such as with Docker and Kubernetes. It feels like one of those things that'll be around for another 10+ years. If anyone is interesed in seeing each pattern applied directly to an open source code base I made a video on that at: https://nickjanetakis.com/blog/creating-a-twelve-factor-app-...

Your podcast is great btw

Thanks a lot for listening to it.

Re: The Twelve-Factor App (2011)

#83

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

Credentials.yml.enc/master.key sorts this pretty well. I have been very grateful for its addition to the stack.

Re: The Twelve-Factor App (2011)

#84
post #34

Earlier quoted context omitted.

The year tags can and do go on anything, they're more for the readers than as some sort of commentary on the timeliness or lack thereof of the content. I think lots of people just find them handy to easily distinguish recent from not-so-recent stuff, as a very basic use case.

I’ve been curious what the oldest year tag applied on HN is.

Mine is this: https://news.ycombinator.com/item?id=22005431 (1539).

Re: The Twelve-Factor App (2011)

#85

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

Seconded, but porque no los dos? I tend to put my applications' env vars in `/etc/environment`.

One pattern that we use at our company is that we have multiple env files, and we launch programs using `run_with_config `. The script loads environment variables from config-file and then launches command.

Re: The Twelve-Factor App (2011)

#86
post #24

Earlier quoted context omitted.

I agree completely. Storing secrets in environment variables is wrong: https://blog.forcesunseen.com/stop-storing-secrets-in-enviro... Even unsetting environment variables leaves them in /proc/self/environ. There isn't a thread-safe way to unset environment variables in POSIX, so even if you `unset TOP_SECRET` from within a program the contents of /proc/self/environ will remain unchanged and available.

How do you actually unmount the volume with kubernetes once the secrets are read and the process is ready? I've never heard of a feature like that.

From my comment farther below:

> If your app can’t interface directly w/k8s, but it can read secrets from a file, you can use a small init program to fetch the k8s secret and write it to a named pipe. This is advantageous compared to mounting as a volume, because the pipe disappears after both ends close their connection to it.

Re: The Twelve-Factor App (2011)

#87

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

I wouldn't put them on a filesystem; do you have any guarantees the secrets are wiped clean after your application is shut down? At least env vars are in memory (...I... think...?), and will be offloaded if the server shuts down.

A secrets manager may be a better option, these days. I don't believe they were a thing in 2011 though.

Also 2011 was 11 years ago, and I still keep this webpage in mind when building server-side software <_<.

Re: The Twelve-Factor App (2011)

#88

I was hoping this would be about twelve-factor authentication

Please delete this comment I don't want anyone getting ideas.

I've just done my taxes using the country's digital sign-in.

- Go to tax website

- Click on log in

- Website tells you to open the app

- App tells you to push a button, this shows a four letter code

- You type in the four letter code on the website

- Website shows a QR code

- Scan the QR code on the app

- App asks you if you want to sign in to the website, hit yes

- App asks for a 5-digit PIN code

I think there was another confirmation, but anyway, there were a Lot of steps and I'm not convinced adding more steps made it safer. I mean they could've skipped the first "type a four letter code" by just showing the QR code directly, it can tell the app what code to use and what website it is, etc.

Re: The Twelve-Factor App (2011)

#89
I personally am stunned that the advice for logging is taken as canon.

I can see using container stderr/stdout as a way to collect exceptions, but using it as a source of exceptions, access logs, authentication events, all mixed together where splunk or "hadoop" will parse it for you? Madness.

Re: The Twelve-Factor App (2011)

#90
post #52

I really dislike 12FA. It's meaningless. The name sounds neat, but it is undistinguishable from "some guy's twelve preferences". Of course advocating for "some guy's twelve preferences" would never be considered serious argumentation in an engineering context. Yet we do for 12FA. I might agree with this or that point, but taking the package as a whole just leads to weaponization and cargo-culting.

So for each of the concerns mentioned, what do you do instead? You're providing criticism without a counter-argument or alternative.
Post reply on HN