AWS AppConfig (FeatureFlag Configuration)

It is 10 pm. In a couple of hours, it would be my best friend's birthday who lives far away. To make this occasion special, I wish that the doorbell of his house rings exactly at midnight and a birthday gift is delivered. How do I do that?

I need a surrogate to press the doorbell when it is time. But I also need him to reach there well before the time, standing silently. I can't afford him getting delayed because of traffic jams, road closures, protests, rushy gift shops, and whatnot. A difficult ask! Even more difficult if I asked him to reach there a day or two earlier. Impossible to get such a service in real life, but one such service is available to me in AWS by the name of AppConfig FeatureFlag Configuration

I can dark-deploy a feature days or even weeks before I want to turn it on for the customers. It can sit on the compute engines silently but would never manifest itself until I turn it on. How do I do it? I just enable the AppConfig FeatureFlag Configuration and the application code immediately notices the change just like the Freeform Configuration update which I had explained in my previous post. It requires no code deployment.

As soon as the FeatureFlag is enabled, it removes the cloak under which the ever-so-useful feature was hidden for weeks ready to manifest itself to the world out there when it is its time... Woah! That sounded legendary.
(Reminds me of Aragorn, son of Arathorn from Lord of the Rings)

Before I proceed further explaining the possible use cases, some major differences between FeatureFlag Configuration and Freeform Configuration are worth mentioning to bring peace to skeptical minds:

• FeatureFlag state can be turned on/off once it is defined whereas Freeform Configuration is always on
• FeatureFlag can have attributes (key/value pairs) that can be used to modify the behavior of the feature without changing its state, but this is optional. It can exist without attributes too but for Freeform Configuration it doesn't make sense to be empty
• FeatureFlag can be marked as short-term so that it can be removed along with the relevant application code when it goes stale and unused
• FeatureFlag can only exist in AppConfig hosted configuration store unlike Freeform Configuration which can be sourced from various additional sources like S3, Secrets Manager, etc

Okay, now to a couple of use cases of FeatureFlag other than just toggling the features on or off

Premium Feature Whitelisting - FeatureFlag can be used to grant access to some special features (e.g. paid content) to a subset of user groups and the list of such user groups can be changed dynamically without redeploying the code.

Logging Verbosity - A microservice generally logs only the WARN or INFO level messages. If the microservice stops functioning properly due to some error, using FeatureFlag the log level can be changed to DEBUG or TRACE to perform quick debugging without a fresh code deployment

FeatureFlag is supremely powerful to enable pushing out features in a no-stress environment by deploying the code well before the release happens. On the release day, you don't worry about the test failures or the deployment issues. On that day you just have to toggle the switch. On that day, you come with the mindset that:

There will be a day when the engineers will be afraid of deploying the code. When there will be blue screens and softwares will crumble down. But it is not this day. This day, I toggle. This day, I deploy!

Remember that the concepts of validation checks, rollbacks, and controlled deployments (using rate controls) apply all the same to FeatureFlags just like they do for Freeform configuration.

Happy Toggling!