Azure App Configuration (continued)

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Azure App Configuration with the link here. This article elaborates on the best practices with Azure App Configuration. 

There are two options for organizing keys – key prefixes and labels. Key-prefixes are the beginning part of keys. A set of keys can be grouped by using the same prefix in their names. Prefixes can have folder path like separator and qualification. Keys are what the application code references to retrieve the values of the corresponding settings. Labels are an attribute of keys and they are used to create variants of a key. A version might be an iteration, an environment, or some other contextual information.

Labels can be used to organize per-environment configuration values which is a common ask from many applications. If a configuration value defines the connection string to a backend database, they  databases are likely to be different between the production and development environments. Since the connection string changes with the database, labels can be used to define different values for the same key. Configuration values can be loaded with a specified label with the following example:

Config.AddAzureAppConfiguration(options =>

options

.Connect(settings.GetConnectionString(“AppConfig”))

.Select(KeyFilter.Any, LabelFilter.Null)

.Select(KeyFilter.Any, hostingContext.HostingEnvironment.EnvironmentName));

The Select method is called twice deliberately, the first time it loads configuration values with no label. Then it loads configuration values with the label corresponding to the current environment.

Azure App Configuration supports import and export of data.  This can be done in bulk as well as for specific key-values.

Data Import and export can be made specific by increasing the refresh timeout, watching a single sentinel key, using Azure Event Grid to receive notifications when configuration changes and spreading requests across multiple app configuration stores. There is an option to bulk import the configuration settings from the current configuration files using either the portal or CLI. The same option can be used to export key-values from app configuration.

 It is also possible to setup an ongoing sync with a GitHub repository with the help of a GitHub Action.

JSON is best suited for key-values as it is evidenced from the widespread use across document stores, virtual date warehouses and object storage.  By setting the default media type of the configuration store as JSON, we get benefits like 1) simpler data management since it is convenient to use with Azure Portal, 2) enhanced data export where the JSON objects will be preserved during data export and 3) native support with application configuration provider libraries in our applications.

Application configurations stores must be backed up and this can be done automatically from a primary Azure App configuration store to its secondary. The backup uses an integration of Event Grid with App Configuration where the latter acts as the publisher of changes to key-values and the former passes it on to interested subscribers which can be a service or a queue.  A storage queue can receive events and use a timer trigger of Azure Functions to process the events from the queue in batches. When the function is triggered, it will fetch the latest values of the keys that have changed from the primary App configuration store and update the secondary store. This helps combine multiple changes that occur in a short period in one backup operation and thus avoids excessive requests to the application configuration store.

The backup of configuration store can be performed across regions which improves the overall geo-resiliency of the application. The primary and the secondary stores should be in different Azure regions for this purpose.

It is recommended that managed identities be used to perform the operations on the configuration store. Managed identities simplify secret management for a cloud application. With managed identity, the application code can use the service principal created for the Azure Service it runs on. Instead of a separate credential stored in Azure Key Vault or a local connection string, the managed identity can be leveraged across function applications and code that is auxiliary to the application.  A managed identity can also be federated so that the same identity works across identity isolation between public and sovereign clouds.