4 ms·

Give an example. Like most things, it's context dependent and there are grey areas, but I think most devs use 12 factor like a north star. I wouldn't block a re

Give an example. Like most things, it's context dependent and there are grey areas, but I think most devs use 12 factor like a north star. I wouldn't block a release due to some minor deviation, but generally lacking alignment should be treated as tech debt as a minimum. If a release regresses significantly in one of the factors, I think it's fair to block or at least force more detailed review to understand why the dev felt the tradeoff was worth it for that release.

cduzz 3y ago
There's the "Plumber Problem[1]" by John Siracusa where you watch a story and see a problem in your specific domain that leads you to mistrust the whole story. With the 12 factor nonsense, I see the guidance of "Dump unformatted logs into stdout and make it someone else's problem; they'll hadoop or splunk it and everyone wins." There is no magic splunk that absolve you (the developer) of generating useful data to logs, if you expect useful data out of your logs. You can't reverse "cow -> burger -> sewage" and shouldn't expect some magic hadoop to reverse entropy without a ton of work. So -- I guess the 12 factor app dictum is fine for some trivial "I rewrote twitter in 80 lines of erlang" app, but in my opinion it is a "if we can land a man on the moon we can land a man on the sun" misstatement of complexity in actually getting things done in the real world. [1] https://hypercritical.co/2023/08/18/the-plumber-problem https://hypercritical.co/2023/08/18/the-plumber-problem
- morelisp 3y ago
  Spoken like someone who has never had to work on a Java application with 22 custom log files, not including stdout, stderr, and two separate syslogs. Yes, if you want useful data from logs you'll need to log useful data, but this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore.
  - cduzz 3y ago
    No, writing files is nearly as bad as writing to stdout -- both imply someone else has to parse the output. If the logs matter -- write them to an API that retains log structure by serializing it. If the logs don't matter, then they don't matter, but typically the logs are used for all sorts of analytics processes after the fact. Asking someone else to parse your data is rude.
    - nightpool 3y ago
      Again, "this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore"
      - cduzz 3y ago
        The twelve factor app says: A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior. That guidance is deeply foolish; I have to assume the rest of the guidance is just as silly for anything but a toy application.
        lexicality 3y ago
        Where does it say "unformatted"? All it says is that your logs should be sent to stdout. You write your logs in whatever structure you want and have something in the runtime environment (k8s, systemd, file redirection in bash whatever) forward them to the eventual storage location. I don't see the issue.
        cduzz 3y ago
        So -- there's a file, that's created by some something in a container emitting a string of bytes. A file must go through a parsing and serialization phase to be useful to a logging infrastructure. Just because you decorate the contents of that file with { and } and other punctuation doesn't make that file a string of json records, until something's read and verified it. I'm supposed to just load it into memory hoping it's json or avro or whatever? Nope, errors happen; there's a limit to the number of bytes that can be sent from one place to another before the kernel may interrupt it (you're writing an application log and your runtime emits it's own debugging message; they get intermingled because they're both being written to a fifo). Maybe this is fine (usually it's fine) but eventually it isn't fine. Use a logging library, categories your logs, maybe start off with stdout but eventually put on some big person pants and use a logging api and use the stderr/stdout for high cardinality exceptions, not "all my logs"
  - jameshart 3y ago
    > this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore Thank you! This is the same thing people miss when they read things like the Agile Manifesto, or about DevOps, or even architectural choices like React's original pitch for one-way data binding - or, dare I say, microservices. You can read these things today, and see flaws - holes in the argument, mistaken assumptions, or misread them as claiming to be superior to things that have been developed since. No - to understand what they are talking about you need to know what was current common knowledge or accepted wisdom in the world when they were written.
- jeremyjh 3y ago
  The reason people pay outrageous prices for Splunk is you can get some pretty decent burgers out of sewage if you know what you are doing, and from personal experience the results can be totally game-changing if you are stuck with a mishmash of different log formats and have to support a large distributed application.
Aurornis 3y ago
> Give an example. I can give an example. The part about sticky sessions is good generic advice for someone building generic web services, but there are situations where sticky session-like functionality or sharding-like behavior might be a better choice. Anyone adhering literally to the 12-factor guide would get hung up on trying to move that data to redis or memcached: > Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis. The guide also has a strong preference for languages like Ruby, Perl, and Python. There’s even a quip about how 12-factor prefers languages with a REPL, which in the wrong hands becomes an argument against using Rust or other languages. People who think the entire world is simple CRUD web apps tend to think that guides like this are completely universal. It’s a good guide for people making common web apps, but it’s not a perfect methodology for every backend service.
- brodouevencode 3y ago
  > People who think the entire world is simple CRUD web apps tend to think that guides like this are completely universal That's the very first point they make: > In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that... Anything not web app/SaaS they express no opinion on.
- willseth 3y ago
  I think it depends on how you interpret "rely". If your app can gracefully recover to a reasonable state from a failure to resume the expected session, then you could argue it's not that reliant on it. Many systems use sticky sessions as simply as an optimization, which is fine. You didn't actually give an complete example. When are sticky sessions a better choice than persistence?

cduzz 3y ago

There's the "Plumber Problem[1]" by John Siracusa where you watch a story and see a problem in your specific domain that leads you to mistrust the whole story. With the 12 factor nonsense, I see the guidance of "Dump unformatted logs into stdout and make it someone else's problem; they'll hadoop or splunk it and everyone wins." There is no magic splunk that absolve you (the developer) of generating useful data to logs, if you expect useful data out of your logs. You can't reverse "cow -> burger -> sewage" and shouldn't expect some magic hadoop to reverse entropy without a ton of work. So -- I guess the 12 factor app dictum is fine for some trivial "I rewrote twitter in 80 lines of erlang" app, but in my opinion it is a "if we can land a man on the moon we can land a man on the sun" misstatement of complexity in actually getting things done in the real world. [1] https://hypercritical.co/2023/08/18/the-plumber-problem https://hypercritical.co/2023/08/18/the-plumber-problem

morelisp 3y ago
Spoken like someone who has never had to work on a Java application with 22 custom log files, not including stdout, stderr, and two separate syslogs. Yes, if you want useful data from logs you'll need to log useful data, but this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore.
- cduzz 3y ago
  No, writing files is nearly as bad as writing to stdout -- both imply someone else has to parse the output. If the logs matter -- write them to an API that retains log structure by serializing it. If the logs don't matter, then they don't matter, but typically the logs are used for all sorts of analytics processes after the fact. Asking someone else to parse your data is rude.
  - nightpool 3y ago
    Again, "this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore"
    - cduzz 3y ago
      The twelve factor app says: A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior. That guidance is deeply foolish; I have to assume the rest of the guidance is just as silly for anything but a toy application.
      - lexicality 3y ago
        Where does it say "unformatted"? All it says is that your logs should be sent to stdout. You write your logs in whatever structure you want and have something in the runtime environment (k8s, systemd, file redirection in bash whatever) forward them to the eventual storage location. I don't see the issue.
        cduzz 3y ago
        So -- there's a file, that's created by some something in a container emitting a string of bytes. A file must go through a parsing and serialization phase to be useful to a logging infrastructure. Just because you decorate the contents of that file with { and } and other punctuation doesn't make that file a string of json records, until something's read and verified it. I'm supposed to just load it into memory hoping it's json or avro or whatever? Nope, errors happen; there's a limit to the number of bytes that can be sent from one place to another before the kernel may interrupt it (you're writing an application log and your runtime emits it's own debugging message; they get intermingled because they're both being written to a fifo). Maybe this is fine (usually it's fine) but eventually it isn't fine. Use a logging library, categories your logs, maybe start off with stdout but eventually put on some big person pants and use a logging api and use the stderr/stdout for high cardinality exceptions, not "all my logs"
- jameshart 3y ago
  > this is a case where 12 factor is so successful / dominant today I don't think you even know what it's arguing against anymore Thank you! This is the same thing people miss when they read things like the Agile Manifesto, or about DevOps, or even architectural choices like React's original pitch for one-way data binding - or, dare I say, microservices. You can read these things today, and see flaws - holes in the argument, mistaken assumptions, or misread them as claiming to be superior to things that have been developed since. No - to understand what they are talking about you need to know what was current common knowledge or accepted wisdom in the world when they were written.
jeremyjh 3y ago
The reason people pay outrageous prices for Splunk is you can get some pretty decent burgers out of sewage if you know what you are doing, and from personal experience the results can be totally game-changing if you are stuck with a mishmash of different log formats and have to support a large distributed application.

Aurornis 3y ago

> Give an example. I can give an example. The part about sticky sessions is good generic advice for someone building generic web services, but there are situations where sticky session-like functionality or sharding-like behavior might be a better choice. Anyone adhering literally to the 12-factor guide would get hung up on trying to move that data to redis or memcached: > Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis. The guide also has a strong preference for languages like Ruby, Perl, and Python. There’s even a quip about how 12-factor prefers languages with a REPL, which in the wrong hands becomes an argument against using Rust or other languages. People who think the entire world is simple CRUD web apps tend to think that guides like this are completely universal. It’s a good guide for people making common web apps, but it’s not a perfect methodology for every backend service.

brodouevencode 3y ago
> People who think the entire world is simple CRUD web apps tend to think that guides like this are completely universal That's the very first point they make: > In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that... Anything not web app/SaaS they express no opinion on.
willseth 3y ago
I think it depends on how you interpret "rely". If your app can gracefully recover to a reasonable state from a failure to resume the expected session, then you could argue it's not that reliant on it. Many systems use sticky sessions as simply as an optimization, which is fine. You didn't actually give an complete example. When are sticky sessions a better choice than persistence?