Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Twelve-Factor App (2025)

12factor.net

Post reply on HN
Print view View original

21–30 of 184 posts

Re: The Twelve-Factor App (2025)

#21

Post by javcasas »

nebezb wrote: post #16

Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes. The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter” Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.…

> this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files

Teach them to use dotenv.

We are moving away from configuration in config files because it is a pain to modify, especially if part of that configuration is secrets. You have to throw everything into your secrets vault of preference, and editing it requires extracting and reuploading the whole thing.

We are currently doing config in env by loading one or multiple secrets per kubernetes pod (mix and match).

What would be your suggestion?

Re: The Twelve-Factor App (2025)

#23

Post by jaggederest »

Tomte wrote: post #13

Every time it gets posted I read through the list and think "export services via port binding… of course a web server binds to a port, of course it‘s decoupled that way, what else would you do" and "treat backing services as attached resources… huh, is that really only about not linking in a database, but connecting using a JDBC string, for example?" So let me ask for once: what am I missing? Why is that interesting…

> Why is that interesting and not trite?

The same reason many older films seem cliche - because they were the first to do it, and it's accepted standard now. Heroku very much shaped how we think of "cloud applications", autoscaling, and containerization.

Re: The Twelve-Factor App (2025)

#24

Post by xander_north »

browningstreet wrote: post #2

I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.

Okay so this may sound odd but this is literally my whole life right now...

Can you explain why do you feel MFA is painful/unsustainable? How would you fix it?

Re: The Twelve-Factor App (2025)

#25

Post by maccard »

VeninVidiaVicii wrote: post #15
browningstreet wrote: post #2

I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.

Every time I leave my phone in the other room to “finally get some work done”, please enter this goddamn number we sent to your SMS, and I close my laptop.

My work uses “okta verify” for everything which is very helpful, as I can sue my work PC as a trusted device or fall back to a yubikey if not. 100x better than random SMS

Re: The Twelve-Factor App (2025)

#26

Post by ipsi »

Tomte wrote: post #13

Every time it gets posted I read through the list and think "export services via port binding… of course a web server binds to a port, of course it‘s decoupled that way, what else would you do" and "treat backing services as attached resources… huh, is that really only about not linking in a database, but connecting using a JDBC string, for example?" So let me ask for once: what am I missing? Why is that interesting…

If you go far enough back in time (this dates back to at least 2011), it's arguing against things like:

For port binding, for example, it used to be that you'd deploy your app to the web application container, rather than bundling them together. e.g., deploying your WAR file to Tomcat, rather than building a self-executing JAR which included Tomcat. The wording is a bit odd, but I think they were trying to make the point very generic, and not specifically about the Enterprise Java world.

For the backing resources, it's a combination of point 3, config often living inside the codebase, applications just shelling out to /usr/sbin/sendmail or what have you, and applications living on the same host as the DB, such that bringing up a new application necessarily required bringing up a new DB as well. Which also made it hard it to scale horizontally.

The whole "12 Factor" thing was partly because Heroku had specific solutions for all of these, so going down this road made it much easier to then sell Heroku, and partly because they really were frustrating. I'd say that the port binding one is more targeted at, say, WebSphere, and all that came along with it, such as sharing a single heap across multiple apps, needing to talk to the WebSphere admins to change configuration, needing to use a "lite" version of WebSphere to test locally, if that was even possible, and so on.

They sound super-obvious these days, but at the time, for a lot of us, they were really nice to see.

Re: The Twelve-Factor App (2025)

#28

Post by jt2190 »

nebezb wrote: post #16

Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes. The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter” Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.…

The unwritten assumption in 12 Factor is: the environment is secure. For example, a production system should always have a secure means of setting environment variables. Said another way: If a random dev can change an environment variable in production either directly by logging in or indirectly by pushing code then there is something very very wrong.

If the dev is pushing code to production they should not simultaneously be pushing environment configs, this is doing two logically distinct things at once: Changing application behavior AND reconfiguring the server environment.

If the dev is adding secrets to their local config and they’re pushing that config to insecure places that means their deployment pipeline is broken and it should be fixed. .env is never committed to source for this reason, for example.

Re: The Twelve-Factor App (2025)

#29

Post by akoboldfrying »

nebezb wrote: post #16

Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes. The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter” Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.…

> Besides being bad advice

What makes it bad advice?

> this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files

You need some way to pass secrets to the app; doesn't every other way also suffer the same kind of issue?

Re: The Twelve-Factor App (2025)

#30

Post by theozero »

.env as we know is full of problems... BUT! check out varlock (https://varlock.dev) - it's free and open source, and we have really modernized and adapted the familiar syntax (a small DSL on top) to make it much better.

Has built-in validation, type-safety, composition via functions, loading with plugins, leak prevention, and much more.

Post reply on HN