An Introduction to Feature Flags

An Introduction to Feature Flags

What are Feature Flags

In software, a flag is “one or more bits used to store binary values.” So it’s a Boolean that can either be true or false.  And you’d check it with an if statement.  In the same context as software, a feature is a chunk of functionality that delivers some kind of value.

Thus, a feature flag, in the simplest terms, is an if statement surrounding some chunk of functionality in your software.

There is, of course, a whole lot more nuance to things than that.  Otherwise, I wouldn’t be writing an entire comprehensive guide on the subject.  But if you came here looking for a quick definition, that’s it.

 

if(configFile["IsHoliday"] == true) {
writeGreetingMessage("Happy holidays!");
}

"A feature flag is a way to change your software’s functionality without changing and re-deploying your code."

Changing Experiences On The Fly

In the above example three pretty basic things going on here, but all of them are important.

  1. We’re reaching outside of the running software to a file to get some configuration information.

  2. If the configuration information says that it’s a holiday, then we get at the feature in question.

  3. The feature in question is to show a holiday greeting.

Now normally, there are a few ways to do the above.

  • We could build some logic that looks at a popular calendar app and determines if it's a "holiday" and we can shut off our message. But what if the calendar has different local holidays? And doesn't that mean I have to build a whole separate service?

  • We could add and remove the message manually and then redeploy our code every time a holiday came and passed. This also means we risk breaking the app every time we deploy our changes.

Change It Remotely!

With a feature flagging platform, our solution is simple, effective, and scalable. Once the Holiday Message code is wrapped in a flag, this functionality can effectively be "turned on or off" remotely - right from a dashboard. All without redeploying or changing code.

 
FF Image

Feature Flag Use Cases

Separating Deployment From Feature Roll-out

There are very different types of risks when deploying code vs deploying features.  For many of us, this seems like a bizarre statement.  How can you separate the two?  Your features are your code, so it’s all the same pile of risk.

Well not really.  Deploying code carries what I’ll call technical risk.  Software might crash or bugs might emerge.  Deploying features carries user-related risk.  Users might hate the new features, or you might have account management issues, for instance.

Traditionally, you just absorb all this risk at once.  With feature flags, you can separate these risks.  You put the new code into production, see how that goes, and then turn the features on later once they’re settled from a technical perspective.

 

Canary Launches

We've talked about deploying code and then throwing the release switch for the new features in one fell swoop.  That’s fine and good, but you can de-risk even further with a canary release.

With a canary release, you introduce the new code gradually to your user base.  The first that see it are the proverbial canaries in the coal mine.  If there is an issue, you can find out with only a fraction of the user base seeing it, rather than everyone inundating you at once with support requests. 

 

Running Experiments

The last product-focused use case that I’ll mention is using feature flags to run production experiments.  The easiest one of these to explain is the A/B test.

With an A/B test, the idea is that you go to production with two different versions of something to see which does the best.  For instance, perhaps you run an e-commerce site, and you want to see whether a green or red “buy” button results in more likes.  You can deploy both buttons and use a feature flag to split your user base in half and see which button performs the best.

You could conceive of all manner of experiments to run like this, for all manner of reasons. The sky is really the limit on how you can use feature flags and the data you gather running experiments to improve your application.

Testing in Production

Conventional wisdom has always held that you don’t test in production.  That’s what QA groups, sandbox environments, and everything else internal are for.  Those are your dress rehearsals and production is the actual show.

But Facebook, Netflix, and others have turned that on its head as I mentioned earlier.  Those companies couldn’t possibly recreate their production environments for test, so they have to run QA in production.  And in doing so, they’ve proved that there’s an awful lot of value to the activity.

So when using feature flags, you can de-risk deploying functionality whose production behavior is unknown to you.  Of course, you always want to test everything you can as early as you can.  But it’s nice to have options.

 

Turning Things Off With a Kill Switch

Just as you can use feature flags to increase the number of users that see a feature, you can also go in the opposite direction.  You can decrease the number seeing it, including decreasing it immediately to zero with a conceptual kill switch.

Of course, this comes in handy when you’ve rolled out a misbehaving feature.  You can turn it off, let life go back to normal for your users, and then live to fight another day.  But it also comes in handy for sunsetting and then decommissioning features as well.

 

Migrations

First up, migrations.  Are you changing over to using a new version of some web service?  Or perhaps you’re doing the iconic database migration?

Traditionally, IT organizations in these scenarios tend to make use of the dreaded forklift upgrade.  They rewrite large swaths of the code to use the new external dependency, then they do a one-time migration that sure better not fail because a rollback will be painful at best and impossible at worst.

Feature flags can get you away from this nerve-wracking approach.  You can just start building calls to the new service or database right into your existing application and deploy them with no fanfare.  Then you can discretely test out the new connection at some low-risk time to see if it’s working.

Anatomy of a Feature Flag

To understand what’s going on here, let’s take a look at the anatomy of a feature flag management scheme in a bit more detail.  As I said at the outset, you can define it extremely simply, or you can get really complex.  These terms will help you understand what’s happening at a more complex level.

Toggle point

In our example, each occurrence of a check for feature.isActive(“holiday-greeting”) represents a single toggle point.  Since a feature is rarely just a few linear lines of code, turning a feature on and off can require many, many toggle points.

Toggle router

The feature.isActive(string) method represents the toggle router.  A toggle router maps the toggle points to the state of the feature flag.  This is how you maintain a coherent, single point of knowledge for the state of the feature across many toggle points.

Toggle context

The toggle context represents contextual information that the router takes into account when computing the feature’s state.  For instance, I mentioned that a “holiday-greeting” feature might depend on the date.  Current date is an example of context.  Other examples might include the logged in user, the geolocation information of the user, a referring URL, etc.

Toggle configuration

In addition to ambient context, you can also control the results of the toggle router for a feature on the basis of simple configuration.  In our example, you might have an ambient context that turns the holiday greeting on, but you also have the ability to manually turn it off.

A More Real-World Kind of Example

With an understanding of feature flag use cases, let’s now expand our toy example to be slightly more representative of the real world.  Imagine an e-commerce application.  It’s not just going to have a single place to greet users, and it’s not going to make the decision to do so based on the contents of some one-off file.

Instead, you’ll probably have a construct like this for the top of a page:

if(feature.isActive("holiday-greeting")) {
print("Happy holidays," + user.name + "!");
}

And then, perhaps something like this at the bottom:

if(feature.isActive("holiday-greeting")) {
printLink("Click to see more holiday daeals", "~/holidayDeals");
}

In other words, when you decide that it’s holiday time, it’s likely that you’re going to have multiple places that behave differently in holiday mode.  Maybe you’ll have dozens.  You’re not going to want to define a different feature flag for each of them or even to re-hash the same implementation in each place.

And then there’s the determining factor for turning on the feature flag.  Do you want the “holiday-greeting” feature to be activated by a manual setting that someone controls?  Or do you want it to activate automatically on certain dates at certain times?  Or some combination of both?

In the real world, the “how” of feature flag management involves some planning and design.  These are not trivial decisions, and they aggregate as your application becomes more complex.

In the above example three pretty basic things going on here, but all of them are important.

  1. We’re reaching outside of the running software to a file to get some configuration information.

  2. If the configuration information says that it’s a holiday, then we get at the feature in question.

  3. The feature in question is to show a holiday greeting.

Now normally, there are a few ways to do the above.

  • We could build some logic that looks at a popular calendar app and determines if it's a "holiday" and we can shut off our message. But what if the calendar has different local holidays? And doesn't that mean I have to build a whole separate service?

  • We could add and remove the message manually and then redeploy our code every time a holiday came and passed. This also means we risk breaking the app every time we deploy our changes.

Change It Remotely!

With a feature flagging platform, our solution is simple, effective, and scalable. Once the Holiday Message code is wrapped in a flag, this functionality can effectively be "turned on or off" remotely - right from a dashboard. All without redeploying or changing code.