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.  

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 serve 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. There is a difference between polling mechanisms and event subscriptions where each has its advantage and can be seen with the help of the size of the changes made to the configuration store. When the changes are infrequent, but the scenario requires immediate responsiveness, event-based architecture can be especially efficient.  The publisher and subscribers get just the data that has changed and as soon as the change happens which enables downstream systems to be reactive and multiple subscribers to receive the notifications at once. They are also relieved from implementing anything more than a message handler. There is also the benefit that comes from the scope of the change that is passed down to the subscribers, so they get additional information on just what configuration has changed.  If the changes become frequent, the number of notifications is large leading up to performance bottleneck with variations in the queue size and delays in the messages.  Instead, when the changes span a lot of keys, it is best to get those changes in bulk. A polling mechanism can get changes in batches over time and then process through all those changes. It can even find only the updates that were made from the time of the previous polling.  This enables incremental updates at the destination. Since a polling mechanism is a loop that perpetually finds changes, if any, and applies them to the destination, it can work in the background even as a single worker. A polling mechanism is a read-only operation and therefore it does not need to fetch the data from the store where the configuration is being actively updated. It can even fetch the data from a mirror of the configuration store. Separation of the read-write store from a read-only store helps improve the throughput for the clients that update the configuration store. Read-only access is only for querying purposes and with a store that is dedicated to this purpose, the configuration store can deploy a suitable technology to host the read-only store that can assist with queries. It is recommended that both the source and the destination of the configuration store changes be made better suited to their purpose.