Stealth Mode: The Secrets of Feature Flags
Feature flags can be leveraged in software development for everything from the resilient roll-out of features to orchestrating complex releases. This article will delve into the nuances of using feature flags, illustrating their application with examples. While they are useful to have in your toolbox, it’s important to critically evaluate — as with any technical decision — the pros & cons. I will offer insight into the characteristics of a situation where they can be helpful as well as the drawbacks and challenges to anticipate with their implementation.
Foundations of Feature Flags
What exactly is a feature flag? Also known as a feature toggle, in its simplest form it is a boolean value externally set and evaluated in the code to enable or disable certain features or functionalities of a given service or system. Essentially, a way of using conditional flow to control the execution of code. The important distinction to make is that the value is not calculated dynamically within the scope of code execution, it is predetermined and defined elsewhere.
Feature Flags in Practice
Now that we know what feature flags are on a basic level, let’s look at them in action. What are situations where they can be beneficial in our development lifecycle? We’ll focus on 2 scenarios:
Scenario 1: A/B Experiment
Innovation is at the heart of everything we do at SSENSE, particularly within the tech department. Business stakeholders are constantly looking to create new features that will improve the customer experience. Despite the research they do to evaluate a feature’s proposed impact, it’s virtually impossible to know the result until customers interact with the change in real time. Feature flags are a great tool to control this by performing A/B Experiments.
Let’s explore a scenario where we identified a pain point for SSENSE customers, as well as a potential improvement, but it involves changes in customer behavior and integrating with a new technology.
There are a number of ways this can be achieved. The simplest would be coding and deploying the change in experience in one shot. Another is handling this in an experimental manner. We call this an A/B Experiment. Let’s look at how this can be accomplished.
Running this experiment for a set period of time and incorporating it with an analytics platform can generate meaningful data about whether customers use the new feature and how it impacts other aspects of their behavior such as attrition and retention.
Scenario 2: Canary Launch
Now let’s imagine that the technology used was novel and complicated and didn’t exist elsewhere in the system. The integrated nature of a microservice architecture means changes to one part of the system can ripple across in unforeseen ways. This is especially true in a distributed system where the team making the changes may not have full visibility into their impact on a tightly coupled architecture. After following a thorough test plan the team decided to use feature flags to incrementally roll-out the new experience in small steps so they could identify and fix any unexpected edge cases. In this scenario, a Canary Launch using a feature flag is a useful tool in their toolbox.
This diagram illustrates how the team incrementally increased the percentage of users that went through the new experience, allowing developers to closely observe the performance of their system and catch any errors before they could have a widespread effect.
Advanced Topics
So far, we’ve looked at how a single feature flag can be used, but how can we further leverage them to be more specific with how we coordinate traffic and orchestrate complex releases? Here we’ll delve into advanced implementations.
A pain point has been identified in the product creation flow. The status quo is a number of user interfaces, each creating different categories of products: clothing, shoes, and accessories. As the product assortment of SSENSE grew, new UIs were created to support different parts of the Buying team, however this is not sustainable from a product or tech perspective. On the product side, overlap can exist between the UIs; is a scarf categorized under clothing or accessories? And on the tech side, synchronous product creation via API calls can put a heavy load on the system when buyers are creating a high volume of products at the same time on several UIs.
The development team implemented a solution with one consolidated product creation UI and addressed the challenge of handling a high volume by transitioning to an event-based architecture emitting to SNS topics and passing messages to queues.
The composite parts of the new flow have been created and tested individually but now the team needs to move from the status quo to the new flow in production. How can feature flags be utilized to create a seamless transition?
First, we can identify places where functionalities will be enabled and disabled. On the left side we will be halting API calls via the various UIs to the integration layer, and on the right side we will start emitting events when products are created or updated. Let’s add feature flags along all these points in order to begin the process of navigating the transition.
Managing 5 feature flags can be a lot to coordinate. Is there a way to unify them to ensure none are forgotten? Enter prerequisite and dependent feature flags.
Prerequisite and Dependent Feature Flags
When orchestrating complex roll-outs, prerequisite and dependent feature flags can be the perfect tool for the job. You’re able to create one global feature flag — one feature flag to rule them all — and specify which dependent flags will be changed and the boolean values they will be set to. Here we can visualize this with the prerequisite flag “NewProductUI”, and dependent flag boolean values it will set in the status quo versus the new flow to halt and start the necessary changes.
And then when we integrate the prerequisite and dependent feature flags using the new flow:
Using Keys
Prerequisite and dependent feature flags orchestrate the high-level flow. But, are there nuanced ways to direct traffic to roll-out to a subset of customers giving the team the opportunity to identify and fix any specific edge cases that arise? Using targeted keys is a useful method. When the feature flag is called, a variable can be passed to it so that, in addition to evaluating the boolean value, it also checks if that variable is one of a predefined set.
Let’s return to our product creation example. The business would like to begin the roll-out by only moving certain brands over to the new flow. A brandId can be passed through the flow to check for that value alongside the boolean. Note that introducing this may require refactoring if that data is not already present everywhere it needs to be evaluated.
Drawbacks
Leaving what is intended to be temporary code for a lengthy period of time can lead to problems, namely being unsure of what code is actively used in Production. In order to proactively address this, teams can create a corresponding cleanup task when adding a feature flag. This guarantees they don’t stay past their welcome in an ever-evolving codebase. Additionally, this ensures a future developer does not stumble across a feature flag referencing a feature that was developed some time ago, and is unclear if it was discarded as an unsuccessful experiment or if it is currently live in production.
New Feature Suggestions
One of the challenges of working with feature flags — especially at a larger company — is ensuring visibility into which iteration of the flow is being used, especially as it’s likely it will be different across environments.
It would be helpful for companies that provide feature flag solutions to create a visual interface so everyone across the technology & engineering department can see the values of the feature flags in each microservice. This could be incorporated with monitoring tools as well and displayed as a dashboard alongside widgets that show performance and other technical metrics.
Conclusion
Feature flags can be a useful tool in your software development toolbox to roll-out new features and orchestrate complex releases. We’ve seen how they can be leveraged to experiment with customer behavior responses to new features and facilitate a smooth transition, all while ensuring system stability when making impactful changes. Prerequisite and dependent flags, as well as keys, can add more control and nuance to your implementations. I encourage you to identify if there are places in your development where they could be advantageous and experiment with implementing feature flags!
Editorial reviews by Mario Bittencourt & Catherine Heim.
Want to work with us? Click here to see all open positions at SSENSE!
