Welcome to another episode of 'Back to Basics'.
I'm Chloe, a Product Manager for AWS AppConfig.
Today we will talk about Feature Flags and how they can help you tune your application
at runtime without needing to restart or redeploy your code.
Thousands of teams at Amazon have used AppConfig internally for years.
We've taken our learnings from those experiences
and built them into the service offered today.
Let's first start out by understanding what Feature Flags are,
and why they're so important to creating a successful development process.
A Feature Flag refers to a modern software strategy
where you can enable or disable certain features without re-deploying your code.
With Feature Flags, you can separate feature releases from code deployment,
build effective strategies for rolling things out,
and have strong insight into how changes impact your application performance.
There are different use cases and types of feature flags, depending on the need.
Today, we're going to focus on the example of a release flag,
which is used to rule out a new feature of an application.
A team of engineers can code a feature,
deploy it while the feature is hidden behind a feature flag,
and gradually make the feature available for all users.
You can do all of this while also monitoring your application's health
and understanding how users are engaging or responding to the new feature.
As you can see here, this feature is released gradually
so that you can limit the negative impact of any unintended outcomes.
There are three different groups shown, and the feature is being released gradually to all three.
This strategy also enables you to analyze the feature release.
How is this feature affecting your app operationally and reputationally?
What if you need a kill switch to turn the feature off quickly?
This gradual deployment method is recommended by AWS as a best practice,
so you can answer these key questions.
And once you know that the feature is safe to release,
it can be turned on to all groups.
Now that you understand more about what Feature Flags are and why they're so important,
let's talk about AppConfig and some of the best practices to be aware of.
With AppConfig Feature Flags you can either deploy a single flag at a time,
or centrally manage and deploy multiple flags together.
The Feature Flag data lives within AppConfig,
and your application can dynamically fetch the data throughout run time.
As shown here, let's say you have a web application.
Your application will dynamically retrieve information from AppConfig
and the Feature Flags will be created and fetched from AWS AppConfig.
So how this works is, first the application gets the configuration data from AppConfig.
Next, the configuration data is fetched from AppConfig to the application.
Now the application will show the feature or not,
based on if the Feature Flag is on or not.
But be careful, releasing a new feature without safety controls
can be similar to pushing untested code to production.
And that's why we have so many guardrails that are built into the service.
First, AppConfig allows you to set validators,
and constraints for each flag.
If a flag's data is non-boolean so for example, a number
you can set an optional minimum or maximum value
for that number to ensure that some accidental flag value does not cause a problem
or even an outage in production.
As I mentioned earlier, you can also release your flags gradually
by setting a deployment strategy for your flag updates.
Flag updates can be rolled out over the course of hours,
limiting the negative impact of any unexpected change.
Finally, if something goes wrong, which sometimes it does,
AppConfig will automatically roll back any Feature Flag update
if a CloudWatch alarm is triggered.
Now let's take a look at an end-to-end architecture that leverages Feature Flags.
To illustrate this architecture, I'll use an example
where you're running a concert ticket marketplace website.
Your team is introducing a new feature to the website that lets viewers preview
10 seconds of a song for a given concert.
This feature's awesome but as a best practice, you want to introduce it gradually and safely.
Especially since adding music could potentially affect the performance of your website.
First, your engineers build the feature, but hide it behind a flag
in AppConfig so that no users can access it.
As you can see in this diagram, the feature has been created, but is not turned on.
This could be as simple as a true or false boolean expression.
So leading up to the launch because you have a Feature Flag,
your code is deployed to production, but no one can access it
since it's hidden behind a Feature Flag.
In this next scenario, you gradually release the music preview feature.
Some of your users will slowly get to access
the new music feature as shown in this example.
Now, since the Feature Flag is toggled on,
when the application goes to fetch data from AppConfig,
the configuration data will indicate 'true' or 'on' to your application.
And this can all be done without pushing any new code to production
or restarting your application.
And since only some users are being exposed to the new feature,
your team can measure how their engagement is,
or how the performance of your website is impacted.
So let's say the feature's actually affecting your website's performance negatively.
You may want a kill switch, and AppConfig lets you do that.
I just showed you the life cycle of Feature Flags,
but this pattern doesn't just apply to a small part of software development.
You can use Feature Flags across various AWS use cases
like AWS Lambda, ECS, and EC2
which just shows you how versatile Feature Flags are.
In this episode, we explored how AppConfig Feature Flags
let you safely release new features to your production environment.
You can use Feature Flags to gradually deploy features
while monitoring the impact on your application.
And by doing this, you can really focus more on innovating faster.
Check out the links below for more details, see you next time.