Serverless Diary: Adding Metadata to Feature Flag Configuration using AWS AppConfig Extensions
I. Introduction
In the previous blog, we looked at how we can use a single feature flag across various components (front end, back end) to manage a consistent behavior of the feature in serverless architectures from a design lens.
This blog focuses on the build details of how we can use the App Config extensions to add metadata to our feature flag configuration at deployment time to customize AppConfig behavior as per our use case.
Note: Please ensure you have checked out the previous blog for a better context before reading any further.
II. The Challenge
“Given I am using AWS AppConfig as a Feature Toggle framework, I want to inject date-time stamp (metadata) into the Feature Flag configuration at deployment time using native AppConfig capability to allow backend lambdas access to this additional information”
AWS AppConfig Out of the box provides dynamic configuration and feature flag management. But if in the past one had to extend AppConfig to cater to a specific use case, consumers had to build something custom around AppConfig, like in the previous blog having the CD pipeline to have that additional logic of adding data time stamp via script or some external source. With the release of AppExtensions this year, we now have the ability to write custom logic and add it as an extension to the lifecycle of AppConfig. This way AppConfig encapsulates and manages all aspects related to feature management configuration. This is beneficial as no custom scripts are required to be managed via pipeline.
Using App Config is simple. We identify the custom logic required to extend the AppConfig service. We codify that in a lambda and then create an AppConfig Extension associating the lambda with custom logic and specifying at what stage during the lifecycle of AppConfig the logic needs to execute.
Let's dive into the details of creating the custom logic and associating that with the AppConfig service. We will extend the figure2 of the previous design, and focus on adding additional metadata (lastModifiedTimestamp) at deployment time to our feature flag configuration.
III. The Design
Let’s look at the sequence of steps from the above diagram (figure1), zooming in on the deployment part:
Step a: A developer creates or updates the configuration profile and feature flag as JSON files and check-in the change into the source code repository.
Step b: The check-in step triggers the CI pipeline that creates or updates the feature flag for the given configuration profile. For example, the pipeline illustrated in the above diagram created a configuration profile in the AWS AppConfig service named ‘FeatureList’ with a feature flag named ‘isFeatureXEnabled’.
Step c: We now initiate the deployment of the configuration profile into an environment test-1. This step checks with the AWS AppConfig service if any configured extensions need to be executed.
Step d: In our case, we have an action to be performed at PRE_START_DEPLOYMENT to trigger MetaDataExtension lambda that injects the feature flag configuration with a timestamp attribute ‘lastModifiedTimestamp
Step e: The updated configuration gets deployed in the test-1 environment’, which allows the feature x lambda layer to access additional meta-data injected by the AppConfig Extension lambda. In this example, the logic checks if all backend instances of lambdas are consistent (logic from the previous blog).
IV. The Build
Let's look at detailed steps for building and configuring a custom extension layer with AppConfig to add metadata lastModifiedTimestamp at deployment time.
Step 1: Create the lambda responsible for adding metadata (timestamp).
Step 2: Create an IAM role to be configured with the App Config Extension. Associate Permissions and Trust Relationships of the role as shown below to allow extension to invoke MetaDataExtension lambda we created in the previous step.
Step 3: Create App Config Extension, and associate the lambda and role created in previous steps with the extension
Step 4: Create the AppConfig Application and associate the App Config extension created in the previous step.
Step 5: Create a configuration profile (type=Freeform) named ‘FeatureList’ with feature flag configuration.
Step 6: Create a test environment (test-1) associated with the appconfig extension.
Step 7: Start deployment into the test environment.
Step 8- Test: Check logs for MetaDataExtension lambda that was triggered as an action point on the pre-deployment step. You should be able to visualize the original configuration without a timestamp and the updated configuration with an injected timestamp value.
Alternatively, we can test the lambda attached with the lambda layer configured to synchronize data with AppConfig
That’s it!! You now have custom logic executing every time you deploy into an environment injecting timestamp into feature flag configuration.
V. Summary
AWS App config extensions are quite a powerful tool and extremely helpful when out-of-the-box feature flag functionality needs to be tweaked or customized to suit a specific use case. At the point of writing this blog, there are 7 action points to choose from where you can have custom logic as required by the business use case. My recommendation is to use App Config extensions over custom logic residing outside in a CD pipeline. This allows all your feature flag related configurations to be centralized and managed in a single place, making supportability and extension easier.