4 ms·

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

by vemv 4y ago

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.

matsemann 4y ago
I disagree. It perhaps started as someone's preference, but the fact that it got so widely known and shared made it something more. Same goes for the Joel Test. And it's not about cargo-culting, it's value lies mostly in having a set of things you can show your company: "this is industry standard, we're far from there and should work on that". Not everything in these lists needs to be done that way. But they're still nice pointers for where to move towards (or beyond).
lliamander 4y ago
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, and it seems pretty clear to me these principles are all more or less correct. In my experience this is now more-or-less best practice* for web services. *with maybe minor exceptions such as accessing secrets from an external vault service.
- vemv 4y ago
  "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?
  - lliamander 4y ago
    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.
holografix 4y ago
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”.
- IshKebab 4y ago
  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 4y ago
    [deleted]
  - afiori 4y ago
    It might not be the most secure method to propagate secrets but the alternatives have significant complexities. In $DAY_JOB we only ever use single-machine docker-compose for deployments and there they work decently.
Cthulhu_ 4y ago
So for each of the concerns mentioned, what do you do instead? You're providing criticism without a counter-argument or alternative.
- vemv 4y ago
  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.

by vemv 4y ago

matsemann 4y ago

I disagree. It perhaps started as someone's preference, but the fact that it got so widely known and shared made it something more. Same goes for the Joel Test. And it's not about cargo-culting, it's value lies mostly in having a set of things you can show your company: "this is industry standard, we're far from there and should work on that". Not everything in these lists needs to be done that way. But they're still nice pointers for where to move towards (or beyond).

lliamander 4y ago

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, and it seems pretty clear to me these principles are all more or less correct. In my experience this is now more-or-less best practice* for web services. *with maybe minor exceptions such as accessing secrets from an external vault service.

vemv 4y ago
"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?
- lliamander 4y ago
  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.

holografix 4y ago

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”.

IshKebab 4y ago
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 4y ago
  [deleted]
- afiori 4y ago
  It might not be the most secure method to propagate secrets but the alternatives have significant complexities. In $DAY_JOB we only ever use single-machine docker-compose for deployments and there they work decently.

Cthulhu_ 4y ago

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

vemv 4y ago
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.