Dark launches with AWS AppConfig
A dark launch, also known as a "canary launch" or "silent launch," is a deployment strategy used in software development and web services to introduce new features or updates to a product without making them immediately visible to all users. Instead of releasing the changes to the entire user base, the new code is released in a controlled environment where only a subset of users or specific internal teams can access and test it.
The purpose of a dark launch is to evaluate the new features' performance, stability, and potential impact on the system before making them available to the wider audience. This approach allows developers to gather valuable feedback, identify and fix any issues that might arise, and ensure that the changes do not negatively affect the overall user experience.
By gradually exposing the new features to a limited audience, developers can closely monitor the system's behaviour, collect data on its performance, and make any necessary adjustments before fully rolling out the update to everyone. This minimises the risk of causing major disruptions or user dissatisfaction.
Introducing AWS AppConfig
AWS AppConfig, a feature of AWS Systems Manager (and not to be confused with the similarly named AWS Config), is a service from AWS which enables you to deploy, manage, and quickly update application configurations. It plays a crucial role in continuous delivery by allowing you to make configuration changes to applications without the need for redeploying the entire application. This approach promotes agility and reduces the risk associated with configuration changes.
Traditionally configuration data is deployed alongside application code, often requiring a complete redeployment of the application when making changes only to configuration. This does not work well at-scale when an application is distributed across potentially tens to thousands of nodes.
Continuous configuration
In a continuous delivery environment, applications are deployed frequently. However, certain aspects of the application, such as feature toggles, environment-specific settings, or behaviour parameters, might need to be changed without redeploying the entire application. AWS AppConfig enables you to define these configurations externally and apply them dynamically to your application without requiring any code changes or redeployments.
At Amazon, this is dubbed Continuous Configuration. I highly recommend AWS CTO Werner Vogels article Continuous Configuration at the Speed of Sound on how AWS AppConfig came to be.
The components of AWS AppConfig
When using AppConfig, it's important to understand the core underlying components.
Application
An application in AWS AppConfig represents the software that consumes the configurations. It can be any software running on various platforms, such as web applications, mobile apps, or server applications. Each application can have multiple configuration profiles associated with it.
Configuration Profile
A configuration profile is a set of configurations and rules that define how your application behaves. It contains the parameters that your application uses, along with their values. Each configuration profile can have multiple configurations, and you can associate it with one or more deployment strategies. You can create different configuration profiles to manage variations in configuration for different environments or application versions.
Environment
An environment represents a logical deployment target for your application. For instance, you might have different environments like "development," "staging," and "production." Each environment can have its own configuration profiles and deployment strategies associated with it.
When defining environments, you also have the option to configure monitors. A monitor is a CloudWatch alarm which monitors some aspect of your application. During a configuration deployment, if a monitor enters an ALARM state, AppConfig will automatically roll-back your deployment. This is a great feature which adds resilience to your configuration deployments.
Deployment strategy
AWS AppConfig provides deployment strategies, such as linear, exponential, or step-based, which allow you to control how configuration changes are rolled out to your application fleet. This is particularly helpful for gradual deployments, A/B testing, or canary releases, where you want to introduce changes slowly to a subset of users before rolling them out to everyone. This fine-grained control ensures that changes can be safely tested and monitored in production.
Configuration: Freeform vs feature-flags
AWS AppConfig supports two primary ways to define configurations, feature-flags or freeform configurations.
Feature flags, also known as feature toggles or feature switches, are a software development technique that allows you to enable or disable certain features of your application without changing the codebase. Flags support various data types such as boolean, number, string and others.
A simple use for feature-flags is to toggle the rendering of user interface elements on frontend applications. Such elements could be conditionally tied to a feature flag where only approved individuals, like developers, can see and interact with said elements. Once a feature is ready to be made public related flags can be updated via a configuration deployment to enable the feature to all users.
Feature-flags are, as the name suggests, is great for controlling individual features of an application. Alternatively, the free-form configuration format is the most flexible option. It allows you to define your configuration data in any format that suits your application's needs. This can be plain text, JSON, XML, or any other data format. While storing free-form configuration is most flexible, you are responsible for ensuring your configuration is valid.
Validation
Like the deployment of code, you must be confident your configuration is valid and error free. Deploying malformed configuration could cause your application to crash causing major disruption to your users. Luckily AppConfig comes with validation built-in.
When writing free-form configurations you can define your validators using JSON Schema or via a Lambda function. Using a Lambda based validator is powerful as while your configuration might be syntactically valid, there may be external conditions affecting the validity of the change. For example, you might code your Lambda validator to detect if the new configuration conflicts with the current live configuration in such a way that might cause issues.
If you opt to use feature-flags, you define validation when you define your flag's attributes. For example, when defining a flag with a string attribute you can provide an enumeration of valid values or alternatively define a regular expression. Likewise with number attributes you can specify minimum and maximum values.
Reading configuration
Reading a deployed configuration can be achieved easily by using the AWS command line utility or by using the AWS SDK. This involves starting a session with AppConfig via StartConfigurationSession and then repeatedly polling the GetLatestConfiguration endpoint on a set schedule.
Recently, AWS announced the AppConfig agent for EC2. With the addition of this new agent, application authors can read configuration data directly from the agent running as a HTTP server on localhost. The agent handles polling AppConfig endpoints and caching the results. There is also a similar existing solution for Lambda which uses a Lambda extension to handle the polling for you.
Extensions
An advanced feature of AWS AppConfig is Extensions. Announced in July 2022, this relatively new feature allows you to hook into the lifecycle actions of a configuration deployment. There are 7 action points in total such as PRE_START_DEPLOYMENT, ON_DEPLOYMENT_COMPLETE , ON_DEPLOYMENT_ROLLED_BACK and others. Simply provide a Lambda function for the action points you are interested in and AppConfig will invoke your functions at the appropriate point during a deployment.
Actions points beginning with PRE_* are unique in that their associated Lambda functions can change the configuration before deployment. For example, this might involve merging data from an external source into the configuration. It's worth noting that actions are invoked after validation so care must be taken when changing configuration this way.
Extensions are hierarchical. An extension associated with an Application affects all Configuration Profiles contained within whereas an extension associated with a single Configuration Profile affects only that profile.
There are also a number of AWS published extensions which integrate with AWS EventBridge, SQS, SNS and others.
Conclusion
By separating configuration from code, AWS AppConfig empowers developers to make real-time adjustments to their applications, reducing deployment complexities and increasing agility. With multiple configuration profiles, deployment strategies, and monitoring capabilities, AWS AppConfig offers a seamless way to roll out updates, control feature flags, and conduct A/B testing. Embracing this powerful service allows businesses to deliver new features faster, respond swiftly to changing requirements, and ultimately provide an enhanced user experience, making it an indispensable tool for modern application development in the dynamic world of cloud computing.
Photo by Tyler van der Hoeven on Unsplash
