In modern software development, specifically when releasing new versions, we often need to deploy the same application with different configurations. Depending on where we are deploying the software and other related factors or requirements, these configurations can change your application’s behavior. Examples of the aforementioned variables — multiple geolocations, new locales, differing use cases, etc.
Software Configurations: Explained
When I write different configurations, it is essential to understand that most of the software is the same. Just some relatively small parts differ. For example, let’s assume you have a retail chain and need to deploy software for the checkout stations. Most of the deployments will be the same. You wouldn’t need entirely different software for every checkout machine based on the shop’s location. Although in some situations, this might be the case.
Back to configuration. Let’s continue with the retail checkout application example. Every station running the application needs to have a unique identifier – this is called configuration. Different countries may require different default languages – configuration once again. You also have the developers who need their own “dev environment” – again, slightly varying configurations. But the software is the same in all cases. You get the idea.
We already store all our software source code changes in version control. In some cases, we have a process that compiles the source code into different kinds of binary assets, archives, or docker containers. The reason is simple: to distribute the right “version” of the software more efficiently.
Separate to Elevate and Optimize
The distributed software asset needs to meet the configuration where it will be running; usually different pieces of configuration that might be relevant to different levels, with some hierarchy involved. This configuration can arrive into the application via different methods. It can be via environment variables, loading of pre-determined files with configuration data, responses from hardcoded or “configured” (using another method), API calls, and more.
The main idea is that this configuration is dynamic and also changes over time. You can wrap ALL of the configuration and deploy it EVERYWHERE each time by bringing it together with the application. But that’s a wasteful activity that can (and should) be better optimized. You can achive this by having a different cadence for the deployment and release of configuration data, which is separated from the app itself.
And this is the main optimization idea – separating the version control and the configuration data management from the application code. This separation works better when the configuration has its own versioning place, with a different deployment process to deploy and release configuration changes. It’s a process that is decoupled from the same one for application deployments, while also having a separate cadence.