A new way how to manage your app configuration - Azure App Configuration

Where do you store the configuration part of your application? In the JSON file? Inside a NoSQL or relational database? Are you using an external solution for this layer? How do you do versioning and feature managing?

There are no wrong answers to these questions, and I’m sure that at least one time in your life you deployed an application with the wrong configuration. In this post, we will talk about the Azure App Configuration. A new service provided by Azure that enables us to store and manage the configuration of our applications.

What is Azure App Configuration Service

The Azure App Configuration Service can be used in combination with any other Azure Services. You can use this service to store your application configuration written in Java and hosted inside AKS or an Azure VM. From this perspective, it is service agnostic and comes with powerful libraries to access the service directly from Java Spring, .NET Core and .NET. At this moment in time, the only thing that it is supported only inside ASP.NET Core without support in other platforms is the Feature Management that we will cover later on.

In one word, the Azure App Configuration can be your central repository for your application configuration. All content can be stored in one location from where the application can consume it. You don’t need to duplicate configuration data or to manage different configuration for different environments. All of this can be done in one central location, that is aware of all these dimensions.

Purpose

This service is useful when you have an application that is hosted in different services. For example, a part of this is inside AKS, another layer is inside Azure VM Scale Sets, and the last one is as a portal inside the Azure Web App. You would like to manage all the application in one central location. As for another type of configuration repositories, you are allowed to change the configuration on the fly, without having to redeploy the application. Restarts might be required based on what technology you are using (and solution).

The values that can be stored inside the service are Unicode string.

At this moment in time, Azure App Configuration Service does not replace Azure Key Vault. Secrets still need to be stored the inside Azure Key Vault system because it is the only location that provides hardware encryptions. If encryption at the store and network level, it is sufficient for the key that you want to store than Azure App Configuration Service, it is the right solution for you.

How to access the content

The content is stored and retrieved based on the Key. Behind the scene, it is a <key, value> storage for your application configuration. There is the moment when you want to group multiple keys based on the component or application layer. This can be done by defining namespaces (flat or hierarchical) using the key naming convention (special character reserved for this are ‘:’ and ‘/’.

myRadu:db:connectionString

myRadu:db:testActiveFlat

myRadu:portal:defaultTheme

As you can see inside the key name, you can find information related to the namespace and hierarchical information. The namespace can be seen as a path that specifies how you can find specific information, including information related to the region (‘myRadu:euRegion:portal:defaultTheme’).

Labels

Using the Label concept you can use the same key name for multiple environments or regions. For example, let’s assume that you have 3 different environments (DEV, TEST, PROD). You can define a label for each environment and store different configuration for each label. For example for “myRadu:db:connectionString” key with DEV label, you can have a connection string that points to a local DB in contrast with “myRadu:db:connectionString” with TEST label that points to the DB that it is used for testing.

Labels can be used to do versioning on top of the configuration. At this moment in time, there is no support for versioning inside App Configuration. The only way how this can be done is by using labels to do versioning to your configuration. Labeling combined with the query capabilities allows us to retrieve the right version of the configuration.

How to access the service from code

From your code, you will need to use a connection string that contains a secret (a secret key). The secret shall be store inside Azure Key Vault and retrieved from there at the moment when your application needs to establish the connection.

A more simple solution is to use Azure Active Directory. There is full support for managed identities that can simplify how you retrieve and access the connection string used to connect to Azure App Configuration from your code.

Another way to access the service is to push the configuration to App Service using a special feature that enables us to export the data directly to our App Service.

Feature Management

My favourite thing from the Azure App Configuration is feature management. It is allowing us to activate application features and managing them from a central location. We can decide to enable some features only to a part of our customers or disable them if we have issues or performance problems.

Testing in production, selective activation or code branch management can be done easily using feature management. Remember that behind the scene they are just some flags stored inside Azure App Configuration Service.

Point-in-time snapshot

This feature enables us to have the full history of a key and to be able to see all the previous values that the key had in the past. In this way, we can recreate a configuration from a specific moment. From another perspective, it can be seen as the key history. The history goes 7 days in the past for now.

How to integrate this service inside my Application

You shall be aware that integrating this service requires you to do application changes. Beside migrating the configuration from your current configuration storage to Azure App Configuration Service, you need to update the layer of the application that accesses the configuration.

If you are using the native libraries, your application can be automatically notified when a configuration value is changed. On top of this, the value is updated dynamically.

Do I have configuration replication cross regions?

No, at this moment in time is a service that runs in each region independently. This means that you can have one instance of the service that runs in Region A and serve your application that runs in multiple regions.

In the same time, if you need a disaster recovery plan, you will need to deploy two different instances of Azure App Configuration service. The synchronisation between the configuration instances is not done out of the box. There is support in Azure CLI to do exports and imports but needs to be triggered by you or by your system.

Inside the application, you need to decide what region you will consider it primary and which one is considered secondary from the configuration perspective.

Summary

Even if this service is still in public preview, it looks pretty good. The current features included inside it makes our life more comfortable, especially when we need to work with a complex system where the configuration is cumbersome.

Pricing information is not yet available, being in public preview. For now, the service is free for use.

Do you want to find more? Check https://docs.microsoft.com/en-us/azure/azure-app-configuration/