I don't understand how a blog post like this can garner, at time of writing, a hundred upvotes. Normally these types of strong statements "Don't do X/Don't use Y" are attention seeking titles with inversely proportional interestingness of its content. That's the first red flag. The second red flag is that the article is not proof-read: from just the first few minutes of skimming, I found two errors that make the text jarring to read (Persistance->Persistence & [you] can not now -> [you] can not know).
Thirdly, the entire central point makes no sense. The author presents this argument to illustrate why environment variables are confusing:
> The environment is now different. What should the program do? Use the old configuration that had the env var set or the new one where it is not set? Error out? Try to silently merge the different options into one? Something else?
The answer is obvious to anyone that knows what environment variables are and how they work: if the variable is set, it should use it, and if it's not, it shouldn't.
The author goes on (again, spelling error) to state that:
> For comparison using JSON configuration files this entire class os (sic) problems would not exist.
What is the practical difference between using a JSON formatted text file containing settings, and a text file containing environment variables and their definitions? For the situation we're discussing here, the answer is frustratingly simple: there is none. This post is a waste of time.
Yes. At the same time, the post missed an appropriate case for avoiding environment variables: when you want dynamic configuration for your services, where configuration values can be changed at runtime without requiring a full redeploy of all the instances.
Of course, that brings its own set of complexity which should be carefully weighed against requirements.
Environment variables are still one of the simplest—and yes, most deterministic ways—to alter behavior of a program.
Such a shame, Enviroment variables are indeed difficult to work with sometimes, who sets them? in which file? Who can/will override them? typo's are also not being caught because editors dont have lists of possible variable and/or what value they are allowed to contain. you might also lose them on different containers.
Enviroment variables should be part of cgroups in some way. I dont like that any program can modify the PATH variable as example. seems like a recipe for disaster in privilege escalation.
> who sets them? in which file? Who can/will override them?
The ops team. Environment variables are a great way of separating operational concerns from business logic. Environment variables are great because your application is agnostic about how the configuration is sourced. Let the ops/infra team handle that.
> I dont like that any program can modify the PATH variable as example.
And ... why not? Child processes can't modify the environment of parent processes. Environment variables flow downwards.
Thirdly, the entire central point makes no sense. The author presents this argument to illustrate why environment variables are confusing:
> The environment is now different. What should the program do? Use the old configuration that had the env var set or the new one where it is not set? Error out? Try to silently merge the different options into one? Something else?
The answer is obvious to anyone that knows what environment variables are and how they work: if the variable is set, it should use it, and if it's not, it shouldn't.
The author goes on (again, spelling error) to state that:
> For comparison using JSON configuration files this entire class os (sic) problems would not exist.
What is the practical difference between using a JSON formatted text file containing settings, and a text file containing environment variables and their definitions? For the situation we're discussing here, the answer is frustratingly simple: there is none. This post is a waste of time.