Azure App Config: Build or Buy?
A colleague and I were discussing the pros and cons of using Azure App Config over the creation of a custom configuration service. On the surface this appears to be another one of those “Build V Buy” scenarios but as we begin to dig deeper, it boils down to tradeoffs, costs and workarounds.
Azure App Config
Azure App Config is, in short, a SaaS offering for exactly what its name implies. It is a key/value pair service (simple configuration values such as HomePageBackgroundColor or AdminEmailAddress), a feature flag service and it’s an integration point for Azure Key Vault. Access to App Config is via an endpoint connection with an API Key. This isn’t dissimilar to access to Azure Cognitive Search or other APIs. As much as I’d like to lengthen this blog post and expand on the 3 capabilities Azure App Config provides, I won’t. You can read all about them on the Microsoft documentation site. What’s important to bring up is the integration with Azure Key Vault and the capabilities of Feature Flags.
Azure Key Vault
The distinction between this service and App Config is that Key Vault is intended to store secrets while App Config is intended to store configuration data. Key Vault is far more secure to access than app config and for good reason. It too can store key/value pairs as well as secrets (a special key/value pair that represents something the “average joe” shouldn’t see). In addition these can be versioned. Last, Key Vault can store certificates. Public Key Infrastructure (PKI) is a time-proven practice for the creation of trusted encrypted connections and for the exchange of information across those connections. If someone were to acquire your private key it’s the equivalent of having your identity stolen.
When App Config is used in conjunction with Azure Key Vault, App Config doesn’t store the value. What it stores is the URI to the secret. It’s up to the client (your application middleware) to retrieve the secret.
Feature Flags
Feature flags are part of roll-forward deployment (or CICD) in which a feature can be added or an existing feature can be replaced and can then be turned on or off. When used correctly (and with a good architecture), a new feature can be rolled to production and tested. If the test fails the flip of a switch turns off the new feature. Developers can then take their learnings from the short production run and improve the feature.
We used this approach to roll out an “improved” search feature on a high traffic web site. When we deployed and turned the feature on, Application Insights and App Dynamics showed us the “Oh Shit” graphs that indicated a system failure wasn’t far from occurring. We turned the feature off and the system became healthy again. In short, feature flags are a great way to load test safely in a production environment.
Feature flags in Azure App Config show great promise in that they support Feature Filters (Rules) in addition to the simple bit flag (I’m on or I’m off, period). They come in 4 flavors, Percentage, Time Window, Custom and Targeting.
Percentage
Percentage based rollout allows “trickling” of traffic to a new feature. It’s a great approach to introducing something with high risk of failure more slowly so as to negatively impact fewer users. This filter also supports groups and users. A user in this case may be a managed user (for running an App Service). In larger architectures, it may be necessary to use elastic scaling and to add additional app services. While Microsoft recommends a minimum of 3 instances to avoid downtime due to patching, your load may need additional app services or you may need to be geographically redundant to achieve an SLA higher than 99.9%. As an example, the percentage filter could be used to target a specific region.
Time Window
Time window filter is pretty much what it states. You can configure your feature flag to be enabled between a set of dates and times.
This one could potentially have a variety of uses. For example, it’s not uncommon for a CMS to have a publishing window for content. An example of this would be a seasonal banner on the home page that shows my friend Lee sporting his bow tie and a seer sucker suit the 1st day of spring and my daughter bombing Ptarmigan (Loveland’s Intermediate slope) on her snowboard the 1st day of winter. During lobster mini season in South Florida, perhaps it would show a picture of me and my buddies with a perfect limit (we can keep 12 per license during mini season and 6 during normal season).
Custom
Custom feature filters can be truly custom (see here) in that you write them or they can be a combination of filters. For a responsive web application, this could be a great way to target iOS browsers or some contextual case.
Targeting
Admittedly, I haven’t spent time on targeting enough to state more than the azure portal does. You can read more about using Targeting here.
Sitting on the Fence
On the surface, one would think that it would be a no brainer to choose App Config and Key Vault over a “roll your own” strategy. The cost to recreate app config and key vault fully would be a project unto itself. Add to that the additional maintenance and upkeep and it would be relatively easy to blow a budget. Keep in mind that in addition to the APIs you also have ready made client packages (nuget) ready to integrate as well as ARM and the portal UI to add your flags, key/value pairs and secrets. Things come slightly unglued when using App Config in conjunction with Key Vault on the development side.
Azure Key Vault Authentication/Authorization
As previously mentioned, App Config doesn’t actually read anything from Key Vault at runtime. Rather, it stores the URI to the secret in Key Vault. The client code and middleware configuration does the actual heavy lifting. The challenge for me presently lies in gaining access to Key Vault. Even following Microsoft’s tutorials, I have yet to successfully build an app that can read from both App Config and Key Vault. I’m in the process of rebuilding some of my POC apps to get a better understanding of “where I went wrong”. I am on a MacBook Pro and running Visual Studio for Mac. Talking to my colleague today, his group seems to be facing similar challenges.
All in all, my current plan is to take the good with the bad and Buy. Building would be a tremendous effort and unlike Azure App Config, wouldn’t necessarily be as repeatable.
