Configuration Management — Environment-specific Configuration and Feature Toggles

Thank you for joining again.

If you haven’t already, I encourage you to review our previous article on Simplifying Configuration Management to reduce stress for Developers/DevOps

Now, let’s delve into the crucial topic of managing environment-specific configurations. We’ve covered the fundamentals of environment-specific configurations, and in this article, we’ll explore various approaches along with their respective pros and cons. We’ll begin with the most basic approach, analyze its advantages and disadvantages, and then progress to more advanced strategies.

It’s important to emphasize that none of these approaches should be adopted blindly. The choice of approach depends entirely on factors such as team maturity, product and business nature, team size, and other relevant considerations.

Step 1 : Using configuration files.

Each language or framework has its preferred method for storing configuration data. Let’s take Java as an example, where properties files are commonly used. The simplest approach to configuration management involves storing all configuration data in application.properties files and running the application. Depending on the environment, different properties files can be specified during deployment to dictate which configuration the application should use.

Pros :

1. Simplifies configuration management.
2. Centralizes all configuration data in one location.
3. Enables dedicated environment-specific configuration files.

Cons :

1. Risks exposing sensitive data like database credentials, API keys, and signatures in properties files.
2. DevOps team dependency for infrastructure-related changes due to configuration file ownership by development.
3. Difficulty identifying and updating configurations on the fly within large property files.
4. Requires system restart for configuration changes as properties are loaded during application initialization.

Step 2 : Using a configuration service/tool

There are numerous configuration management tools available in the market, and if not, the development team can create a custom solution to provide configuration data to the application based on the environment. At application startup, the system would connect to these tools, retrieve configurations, override property file values, and then make the system operational for end users.

Pros :

1. Enhanced security through DevOps-managed access controls, ensuring sensitive production configurations (like database credentials and API keys) are accessed dynamically and not exposed directly.
2. Facilitates infrastructure changes managed by DevOps, as configurations are handled within the configuration tool under controlled policies.

Cons :

1. Risk of errors due to the complexity of the dataset and limited familiarity of DevOps team with specific configurations, potentially leading to incorrect updates that could impact the product and business.
2. Continued need for service restarts during configuration changes, as configurations are loaded during application initialization..

Step 3 : Application Configuration tables (Also Solves Feature Toggles)

To achieve our end goal, we’ll categorize configurations into two types:

3a. Infrastructure related configuration.

These include essential settings like database credentials and access keys for third-party systems needed to start the application. Given their stability and infrequent changes, we’ll use the approach outlined in Step 2 to manage these configurations.

3b. Feature related configurations.

Once the application is operational with infrastructure configurations managed, we’ll use an application configuration table to handle feature-specific settings. Any sensitive data required can be encrypted and stored in this table, with the decryption key isolated within the infrastructure-related configurations.

At application startup:

1. Connect to the configuration tool to retrieve infrastructure-related configurations, including database credentials.
2. Access the application configuration table in the database to load all feature configurations.
3. Override property file values with the retrieved configurations.
4. Start the application.

Pros of Step 3

1. Enhanced security as all sensitive information remains protected.
2. Isolated configuration data for each environment due to separate configuration tables.
3. DevOps team has full control and ownership of infrastructure changes.
4. Simplified configuration management via database queries rather than manual searches.
5. For making configuration changes without requiring a system restart, we can implement a mechanism to update configurations using scheduled tasks or an internal API for configuration refresh. While the choice between these approaches depends on various factors, both methods empower the development team to manage pilot activities, scale-up initiatives, and feature toggling on-the-fly without disrupting service. This capability enhances flexibility and agility in managing configurations, allowing for seamless updates and adjustments to application settings without the need for downtime or service interruptions.
6. Clear audit trail for configuration updates through API-based changes, documenting who made changes and when.

Cons :

1. Complex structure of storing all the configurations.
2. Managing a complex structure for storing configurations requires skilled developers to create, maintain, and troubleshoot any issues that arise.

This approach streamlines configuration management while ensuring security, scalability, and control over application settings.

These are my current insights into configuration management for applications. I will continue to expand and refine this knowledge based on future learnings. Thank you.