Simplifying Configuration Management to reduce stress for Developers/DevOps

Thanks for connecting again.

When I started learning the mindset of a software engineer I quickly realized that there’s more to it than just coding incessantly, one of the major terms was around the configuration data. Initially, it started with keeping some basic information, but later on, it expanded to many different levels. When I started my research on complete Configuration Management, I found a few people talking about API configuration properties, a few talking about the feature configuration, a few discussing the version management configuration, and many more. So, I am sharing consolidated information (basis my learnings) about the same gathering all my learnings with different leaders, managers and mentors I interacted with. I’ve aimed to present this information in a straightforward manner. I hope you find it helpful.

What is Configuration Management?

In simple terms, Configuration refers to any setting used within software. There are several types of configurations:

1. Static Configuration
   These configurations are set once and generally remain unchanged. Examples include the domain name of an application, the package name/group ID/artifact ID of a project, or the bundle ID of an iOS application.
2. Customer Specific Configuration
   This involves configurations that can vary from one customer to another. These configurations are managed regardless of whether the software architecture is single-tenancy (where all customers use one copy of the application and share common resources like a database) or multi-tenancy (where each customer gets their own copy of the application and resources). Examples of such configurations include interest rates or fees in online banking applications, types of loans in a banking domain, commissions charged on sales by e-commerce aggregators, or specific features tailored for individual customers in a multi-tenant setup.
3. Environment Specific Configuration
   These configurations vary depending on the environment in which the application operates. These environments are primarily created to isolate customers for different environments. Such configurations can include database credentials, settings for logging and monitoring tools (such as Papertrail/ELK, Datadog, Airbrake), and credentials for third-party aggregators like payment gateways. For instance, in a typical Java application, we use the application.properties file to define these environment-specific properties. Later, we'll discuss the various advantages and disadvantages of using such files.
4. Feature Toggles
   When developing a new feature or enhancing an existing one in a product, deploying directly to production can be risky due to the large customer base. Any issues could potentially jeopardize the entire business. In the Continuous Development approach, product changes are initially deployed to production for a limited set of users, known as the pilot phase. Feedback is collected from these users before a full-scale release to ensure stability in the production environment.
   Additionally, there are cases where customers request to temporarily disable specific changes. In response, developers must perform rollbacks. To address these scenarios, we utilize Feature Toggles, which involve keeping configurations specific to application features. A feature toggle determines whether to execute new code for a particular feature based on its configuration state; if the toggle is on, the new feature is activated; otherwise, the existing logic remains in place.

There may be additional types of configurations depending on the architecture and specific nature of a business, but the ones discussed here are among the most commonly used across various products.

There are ongoing debates about the best practices for storing these configurations. Drawing from insights provided by multiple industry leaders, I’m sharing my current learnings. I hope this article helps readers understand the real impact of their actions. It’s important to note that these approaches are not definitive and may be implemented differently by various individuals and teams.

Handling Static Configurations :

Since static configurations remain constant and do not change, they can be embedded within our development code. Additionally, in single tenancy systems, these configurations remain consistent across all customers, eliminating the need to manage them separately for each customer. For tasks like setting domain names or URLs, these one-time activities can be managed by the DevOps team during the initial stages of creating the production infrastructure.

Handling Customer-specific Configuration :

To manage customer-specific configurations in both single-tenancy and multi-tenancy systems, a tenant configuration table can be employed.

Why do we avoid using environment files or third-party configuration services? (Click the link below to explore these approaches)
— -> These methods primarily load configurations at application startup, making it challenging to manage dynamic updates.

When updates are needed, using the aforementioned approaches requires involving DevOps to restart the application, creating external dependencies and potential delays depending on the team’s priorities. Frequent application restarts can also impact business operations.

Additionally, some use cases require customers to have a separate interface to modify values or configurations (e.g., toggling features) and see changes instantly. Environment files and configuration services are static, making it difficult to support such use cases without application restarts.

For more insights into environment-specific configurations, please refer to another article as this is a complex topic. Click on Configuration Management — Environment-specific Configuration and Feature Toggles