Being blind
Two problems come up when you look at issues in a specific area, in this case, configurations. The first problem is you become blind to other solutions that don't fit your view of the issue. Secondly, you learn of all the other ways that other people use or experience that specific area. It is this second point that I want to touch on.
Conversations on configurations
After the first post, I had some conversations about configurations. These coworkers all had valid and different points to bring to the conversation. Some of these points are outlined below.
Performance considerations
From one conversation I was having about configurations the topic of performance came up. What is the performance hit you get when loading a configuration file from disk compared to reading the value from an environment variable or having it hard coded within the code base? If the application is a long running application that allows the user to reconfigure the application while it is still running, what performance hit does that take especially if the configuration file is very large?
Error handling
Errors in the configuration file and how are they handled? This again around a long running application or service that is maybe is being managed by an SRE team. If a member of the SRE team miss formats one setting in the configuration file of a running application will that crash the application and bring down a service? So this could happen by not having a closing quote on a string, comment marker missing from some comments. There are many ways that the configuration file could have errors within the formatting. Should these errors crash the application? Where environment variables are configured there is a higher change the application can handle formatting errors. This might raise application errors for the functions that need that configuration but it is less likely to crash the whole application. While any error in the application is not wanted it can be better than bring the whole application or service down which would create for more work for the SRE teams.
Fleet wide deployments
This leads on to an interesting point that was raised during a different conversation. What happens if you need to change a configuration setting across a fleet of applications. This scenario comes from running a service on OpenShift. Lets say the service that is running has a large number of application instance deployed. The application uses feature flags in the configuration to control when to on turn a feature and the application uses GitOps to keep configurations in sync. If the new required configuration is checked into the configuration repo all the application instance will see the new changes almost at the same time triggering a rollout of the new version across the entire fleet. This could overload the cluster and introduce down time within the service. In this case you want to be able to set environment variables on a controlled number of instances so as to manage the rollout. After this the new configuration settings can be added to the configuration repo meaning any new deployments will have the correct settings. As I am writing this section I think there is a bit of information that I am missing. That is how does the commit to the configuration repo not trigger a rollout even for the instances that have the environment variable. With that said it still points out a use case that I never thought of while first looking at this topic.
Pod V's desktop
One other point that came up was where is the application running or intended to run. This is looking at the application from the point of running on user desktop environment compared to running as a single application within some pod on a OpenShift cluster. In the latter naming of environment variables don't matter as much. The chance of other applications running in the pod using the same environment variables becomes much lower. While on a user desktop there is a much higher chance of the conflict happen due to the number of applications a user can have installed.
Closing points
From the different conversations I have had, I still believe my main point that configurations should be stored in human readable files. Now I can see where and when environment variables can be used to great affect. One person said the environment variables should be used to override existing configurations not define the configuration. Everyone's use case may be different and it is finding that common ground that is important when looking at any area of interest.
