Twelve Factor

• https://12factor.net/
• ITIL for influencers

III

• environment variables are too crude for typical config workloads
  • and the .env mechanism crumbles as soon as your values aren't nice enough, or cease to be independent of one another
    • furthermore, why is this important file marked as hidden
  • pass an aridity config via one environment variable instead

V

• as insurance against unpleasant surprises, a deployment should only be able to access config specific to that environment (along with config common to all envs)

X

• differences between envs must be inspectable, so that the confidence you gain in one env actually means something in the next

XI

• logging goes to stderr which is already unbuffered and this is consistent with the rest of the world, not stdout which is fully buffered (would be line buffered if connected to a terminal)
• wishful thinking to characterise logging as an event stream as much of it is under the control of libs or even other processes, and logs are typically untested
• structured logging to satisfy the demands of visual tools is expensive, plain text is sufficient for investigating incidents using ordinary unix tools, and it compresses well
  • for example fail2ban works just fine on plain text using regex, and json actually gets in the way
  • use dedicated streams for anything that needs to be notified of events, do not abuse logging for this purpose