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

The Twelve-Factor App (2011)

12factor.net

Post reply on HN
Print view View original

91–100 of 106 posts

Re: The Twelve-Factor App (2011)

#91

Post by ninkendo »

cduzz wrote: post #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.

As opposed to what, exactly? Should I be reinventing logfile rotation inside my web app? Why not just log to a stream and have a dedicated logging service figure out what to do with it? It sounds reasonable to me.

Re: The Twelve-Factor App (2011)

#92

Post by IshKebab »

holografix wrote: post #71
vemv wrote: 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.

I can’t tell if you’re being sarcastic or not. In case your not, The 12 Factor App was a seminal piece of work that underpinned the foundation of so much we take for granted about “cloud native” today. It was mostly written by the folks who started Heroku and were doing containerisation and elastic scalability before Docker existed. It really isn’t “some guy’s preference”.

I wasn't seminal. All the things in the list were already being done, someone just wrote down what they thought were best practices. Some of the things in the list are widely viewed as bad advice (e.g. using environment variables).

Re: The Twelve-Factor App (2011)

#93

Post by [deleted] »

IshKebab wrote: post #92
holografix wrote: post #71

Earlier quoted context omitted.

I can’t tell if you’re being sarcastic or not. In case your not, The 12 Factor App was a seminal piece of work that underpinned the foundation of so much we take for granted about “cloud native” today. It was mostly written by the folks who started Heroku and were doing containerisation and elastic scalability before Docker existed. It really isn’t “some guy’s preference”.

I wasn't seminal. All the things in the list were already being done, someone just wrote down what they thought were best practices. Some of the things in the list are widely viewed as bad advice (e.g. using environment variables).

[deleted]

Re: The Twelve-Factor App (2011)

#94

Post by vemv »

Cthulhu_ wrote: post #90
vemv wrote: 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.

You didn't get the point I conveyed which wasn't criticism of each point.

Instead of promoting any arbitrary set of N "factors", we should think in a Unixy way: each concern ("factor") is considered isolatedly, and composed with other concerns however we see best for a given project/context.

Re: The Twelve-Factor App (2011)

#95

Post by vemv »

lliamander wrote: post #68
vemv wrote: 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.

I'm not sure how you can say it's meaningless. It's clearly not just a bunch of babble that you often see in business writing: each of these is a specific, concrete suggestion. I'm also fairly sure it wasn't just one guy's preferences, and in any case those preferences were born out of experience with the early days of the web. I've worked on web services that did not follow those principles as well as ones that do,…

"12 factor app" is exactly as meaningful as "24 factor app" or "100 factor app", i.e. not at all.

Who gets to say how many "factors" are relevant? What's the common thread of the 12 factors?

Re: The Twelve-Factor App (2011)

#96

Post by lakomen »

Just today I pondered how you can resell old content as new. One example was a song that I heard as a young teen, strawberry fields by some random Brit on MTV. I liked the song to only find out years later that it's a song by the Beatles.

A bloody song by the Beatles with some new drums and some spaz spazzing to the music...

Well there you go again... the 12factor app from 2011. A few years ago when I was browsing job offers that was a hard requirement in job ads I saw. Now it's forgotten, but since k8s and cloud hype all I see is bs cloud hype job ads. Microservices and cloud hype agile scrum blockchain ai machine learning devops bs bs bs. When will they ever learn when will they ever learn...

Why can't we get away from hype driven development and recruitment?

For the record, I'm not saying 12factor is a bad idea, it actually great, refined by experience. But in the newsosphere it was forgotten. I see it as a standard that makes sense, but I'm getting annoyed that that 11 year old site is something that makes the hacker news. And how the memory of us humans is so limited. Of course young people starting out likely never heard of 12factor. So it's new and shiny for them. Goto 10.

Re: The Twelve-Factor App (2011)

#97

Post by zmmmmm »

danenania wrote: post #50
numbsafari wrote: post #14

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.

EnvKey[1] can help with process reloading, and can facilitate both restarts and hot reload updates. (Disclaimer: I’m the founder.) The pros/cons of environment variables vs. files (or other approaches) is also something I’ve thought about a lot while working on EnvKey. We use environment variables as a default approach, since it seems to be the most common way to pass secrets/config to a process in the wild and we wa…

EnvKey looks great!

Only one thing strikes me as unfortunate, which is it seems like it fragments the development process because now your code history is tracked in git but your config history is in EnvKey. It means everything I do is duplicated (for example, tags, branches etc). It isn't clear to me how I would take, for example common operations such as rebasing one git branch on another and replicate the same on the two EnvKey branches involved.

We track all our non-sensitive config in git for this reason - then merging two branches is literally merging the config changes. However, we don't have any of the nice features EnvKey is doing like service restarting, inheritance, secret management etc.

Just curious if I'm missing something here or you have a strategy for what I discuss above?

Re: The Twelve-Factor App (2011)

#98

Post by zmmmmm »

DLion wrote: post #78

I prefer the 15-factor app, as evolution of the 12: https://domenicoluciani.com/2021/10/30/15-factor-app.html

The three extra ones seem like good areas to think about but low effort and not well defined at all in the link ...

> We can use machine learning towards those metrics to derive future business strategies

really????

> Make sure all security policies are in place

no information

Re: The Twelve-Factor App (2011)

#99

Post by lliamander »

vemv wrote: post #95
lliamander wrote: post #68

Earlier quoted context omitted.

I'm not sure how you can say it's meaningless. It's clearly not just a bunch of babble that you often see in business writing: each of these is a specific, concrete suggestion. I'm also fairly sure it wasn't just one guy's preferences, and in any case those preferences were born out of experience with the early days of the web. I've worked on web services that did not follow those principles as well as ones that do,…

"12 factor app" is exactly as meaningful as "24 factor app" or "100 factor app", i.e. not at all. Who gets to say how many "factors" are relevant? What's the common thread of the 12 factors?

I'm struggling to understand your criticism. Why the authors decided to put 12 instead of 24 or 100 (or whatever) is irrelevant. What's relevant is whether the factors themselves are meaningful.

The common thread is covered in the introduction. It's about building services that back web applications in a way that makes it easy to deploy and manage them.

Re: The Twelve-Factor App (2011)

#100

Post by zach_garwood »

Parrot_NTheKing wrote: post #85
zach_garwood wrote: post #15

Earlier quoted context omitted.

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.

I like to do something similar with my personal projects: `set -o allexport && source /ect/environment && set +o allexport; command`
Post reply on HN