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.…
Even putting secrets aside, the environment is a crappy place for config data. It's got a maximum size cap, is trivially introspectable by via any process that can read `/proc`, and sucks at representing hierarchical or structured data beyond k=v. The proliferation of tools that come up with all sorts of contortions to encode e.g. JSON-ish structures into the environment is evidence that this ain't a great way to go.…
It's ok, it's a kv store.
> is trivially introspectable by via any process that can read `/proc`,
It's ok, containerized apps are expected to run in isolated environments where you are the only one with access to this info.
> and sucks at representing hierarchical or structured data beyond k=v.
It's ok, it's a KV store.
If it isn't, you are doing something terribly wrong.
Virtually all config systems developed in the past decade follow this pattern, where multiple config providers are applied hierarchically and env vars are the last chain in the chain of responsibility that overrides all other providers. It works well.