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.  

App Configuration treats all keys stored with it as independent entities. App configurations doesn’t attempt to infer any relationship between the keys. Aggregation is made possible with the help of labels. Application code can perform configuration stacking.

Excessive requests made to App Configuration can result in throttling or overage charges. Requests can be reduced 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. 

Client applications demonstrate two common risks. First, they use a connection string which is exposed to the public and second, the scale of the requests from client applications can be excessive. It is recommended that a proxy be used instead between the applications and the app configuration store.

Azure App maintains a record of changes made to key-values. This record provides a timeline of key-value changes and allows us to reconstruct the history of any key-value to fall back to a value to an earlier point in this history. The az appconfig revision list command enables us to retrieve all recorded changes to the key-values.

App configuration is particularly helpful for feature management. This is a software development practice that decouples feature release from code deployment and enables quick changes to feature availability on demand. A feature flag can be used to toggle the feature on or off.

Feature flags serves to wrap new functionality under development so that the feature can be shipped even if it is unfinished. It will no longer need to maintain code against multiple development lifecycles. It can be tested in production by limiting access to beta customers. It can also be used to roll out new functionality incrementally in production.  It can also help to disable a feature without rebuilding and redeploying the application. The feature flags can be used to segment a user and deliver a specific set of features to each group. All feature flags used in an application can be externalized. One way to avoid proliferation of key-values is to remove the obsolete ones and promote the feature to current source.

Azure App configurations events enable applications to react to changes in key-values. This eliminates code or expensive and inefficient polling services. Events are pushed through Azure Event Grid to subscribers. Common App configuration event scenarios include refreshing application configuration, triggering deployment or any configuration-oriented workflow.