App Configuration Service is, at the most basic level, an independent store for application configuration settings. It’s not tied to any particular application, it’s not tied to a continuous integration platform, it’s not tied to anything other than Azure. It’s just a very flexible key/value pair store.
Key Features
- Fast and easy to provision
- Ability to define key/value pairs with configuration settings
- Ability to define and manage state of feature toggles
- A powerful labeling system for categorizing and querying settings
- Audit history
- Azure Managed Identity support for easy integration with Azure services
- KeyVault integration for exposing secrets
Why Do We Need This?
Application configuration is hard. It shouldn’t be, but it is. In the good old days, we had configuration files, and we used some method of transforming the configuration files at the time of deployment on an environment-by-environment basis.
Nowadays, we still have configuration files, but the number of options for actually getting configuration values into a running application for use has expanded. We have
- Loading from configuration files
- Loading from environment variables
- Loading from our cloud provider (in Azure’s case, Web App settings)
- Loading from a secret store (in Azure’s case, KeyVault)
- Passing values in at application startup
What a mess! There are so many options, and none of them are strictly better or worse than any other option. I don’t like messing with configuration files:
- Transforming them is a pain
- It encourages you to store application configuration inside your continuous delivery system resulting in tight coupling of your application’s configuration to a tool that has nothing to do with your application
- Secrets end up exposed in plain text in the config file, representing a security concern
Environment variables are better, but still have some downsides:
- If you’re running your applications in any sort of multi-tenant environment (i.e. an IaaS VM), environment variables are accessible to the other applications. Another security concern! That’s less common these days, but it still comes up a surprising amount!
- You still have to store and set the environment variables via some mechanism. It’s less of a problem if you’re, say, running your application in Kubernetes and can easily control the environment variable situation
Loading from an Azure App Service’s app config section is more or less an extension of environment variables. It’s an okay option, but it just moves the place where your application’s configuration is tightly coupled up a level – now instead of being tightly coupled to your continuous delivery system, you’re tightly coupled to the ARM templates that create your environment. If you’re starting to think multi-cloud, that’s not ideal either!
KeyVault is a great option, and it’s actually very similar to App Configuration, but the key management capabilities aren’t as robust as App Configuration. It’s not a bad option, but I’d say that App Configuration is strictly superior and integrating App Configuration is just about the same as integrating Keyvault into your application, so you might as well use KeyVault for secrets and certificates and App Configuration for, well, app configuration.
Passing settings in at runtime is just plain messy. Don’t do that.
Obviously, you can (and probably do) use a combination of these methods, but it’s just overall an ugly and potentially confusing experience. You end up having a visibility problem with not knowing which source of configuration is being used by the application, potentially resulting in configuration-related bugs.
And none of these handle the problem of common settings that are the same across multiple applications (or even multiple instances of an application) or controlling feature toggles. That’s where Azure App Configuration Service comes into play.
App Configuration is more or less a plug-and-play external configuration provider. No messing around with big, complex config files, or environment variables – your application just loads settings directly from the cloud at runtime as needed. Updating an app setting doesn’t require redeploying the application, the way it would if you were using configuration files!
How Do I Use It?
There are NuGet packages available for common Microsoft development tool chains (.NET Framework/Core and ASP .NET) and for Java. For everyone else, there’s a REST API. Take a look at the documentation!
Integrating it into an existing .NET Core application only takes a few minutes.
Feature Toggles
Probably my favorite value add in App Configuration is the built-in support for feature toggles. Feature toggles are a key element in modern continuous delivery, allowing you to keep your in-development features integrated into your trunk while still deploying to production, without exposing features that aren’t ready for use to your end-users.
Once integrated into your application, you get first-class support for attribute- and Razor-markup based feature toggle capabilities.
This is especially powerful when you’re using a microservice architecture with a new or upcoming feature that impacts multiple services. Normally, you’d have to hold off merging the change until everything was ready across all services, then carefully manage the rollout of the services to ensure that all the affected services are deployed. With feature toggling, you just implement a common feature toggle across all the services. Deploy each individual service as soon as that service is ready. Then, once everything is done and deployed, flip the feature toggle and the new feature will magically come on-line across all of the different affected services.
Final Words
Even if you’re not going to take advantage of feature toggles, I strongly recommend taking a look at App Configuration – it’s cheap, it’s powerful, and it helps you centralize and manage a traditionally finicky and tricky part of application deployments.
