Using Multivariate Feature Flags In LaunchDarkly To Drive Operational Settings Like Minimum Log Level

515

Originally published here by Ben Nadel on March 23, 2018.

After having used LaunchDarkly as our feature flag service provider for several years, I’m taking a fresh look at their documentation in order to see what new hawtness they offer above and beyond the traditional On / Off toggle. Yesterday, I looked at LaunchDarkly’s ability to target users based on Personally Identifiable Information (PII) without having to actually send said PII to the LaunchDarkly servers. This morning, I wanted to take a look at their new “multivariate” feature flags. Rather than just a Boolean setting, these feature flags allow engineers to define custom settings. So, rather than a simple Boolean, a multivariate feature flag could be a list of different strings, numbers, or Booleans. To explore this concept, I wanted to define an Operations feature flag that would allow me to change the minimum log-level being used by a given application.

By default, all of the LaunchDarkly feature flags are Booleans. Which means that they result in either a “true” or “false” value. A “multivariate” feature flag can also provide a “true” / “false” dichotomy. But, it can also provide an arbitrary set of string values. Or number values. Or some combination of the three. So, if we want to create a long-lived Operations feature flag to drive log-level in our application, we can create a multivariate flag in which each option defines the minimum log-level as a string value:

As you can see, this feature flag, “operations-minimum-log-level”, defines the following string variations:

  • error
  • warn
  • info
  • debug

With this flag in place, I get then enable targeting that delivers one of these four string values:

Now that we have our multivariate feature flag defined, let’s look at how we can use it in the code. Like yesterday, I’ve created a simple node.js loop that executes once every second. This time, however, the loop is going to be consuming an instance of our Logger service. The Logger service will expose traditional logging methods like .error(), .warn(), and .info(). However, internally, the service will examine our “operations-minimum-log-level” feature flag to see which, if any, of the logging requests should be ignored.

As you can see, we’re using various log-level statements to trace the control-flow through the application. We’re also using some randomness to throw errors such that we can exercise all of the available log-levels.

Now, if we start the node.js process in “debug” mode and then switch our multivariate feature flag over to “warn” mode, we get the following terminal output:

As you can see, when we start our operations feature flag, “operations-minimum-log-level”, in “Debug” mode, our Logger service outputs all of the log messages. However, when we switch the feature flag over to “warn” mode, our Logger service only outputs “error” and “warn” messages. And, like yesterday, if you watch the video, you can see just how fast LaunchDarkly syncs the rules database in the background.

Historically, I’ve been using feature flags to safely rollout new features, with the intent of removing the feature flag once the new feature has been “proven.” With multivariate feature flags, however, the concept of a long-term feature flag starts to become a lot more powerful. Now, we can really use LaunchDarkly to help drive actual site operations.

Of course, we can certainly have long term Boolean variations. However, allowing for arbitrary string value variations really opens up new possibilities. In fact, just yesterday, Ted Pennings – one of my co-workers at InVision – mentioned using custom variations to drive site-status messaging:

What a great idea! It’s exciting to see LaunchDarkly really maturing their product. There’s lot of feature flag goodness to start using.

*  *  *

Ben Nadel (@BenNadel) is the “Co-founder of @InVisionApp, Inc. I live and breathe #JavaScript, #NodeJS, #AngularJS, #ColdFusion, and #UserExperience.”