Skip to main content

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/

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP