Feature Flags are Ubiquitous

Martin Fowler began popularizing feature flags in earnest over ten years ago. Modern CI/CD pipelines count on being able to do trunk-based development, and word has gotten out that this is just the beginning of the benefits to feature flags. Many shops have built their own flagging, only to discover that more advanced features are costly to implement. Whether you’re new to feature flags, or considering them for the first time, there is a bewildering number of options available.

This article is not a product review. Instead, Split would like to set the bar for great feature flags. What does a great feature flagging platform include? How does it handle the privacy of its guests? Is it scalable and performant? Does it seamlessly enable experimentation?

Split is in the Cloud

First, Split is a cloud-based feature data platform. At this time, we do not have an on-premise offering. While you can put Split SDKs into an off-the-grid “localhost” mode, this is intended mostly for high volume testing.

When you create and set a feature flag in Split, the Split cloud immediately stages it to the Fastly CDN. Fastly has points-of-presence around the globe. This stages the feature flags for consumption by the Split SDK.

Split SDK

Split offers both server-side and true client-side SDKs. The client-side SDKs include React, Angular, iOS, Android, Flutter, React Native, and Javascript.

The Split client SDKs do something odd. They connect by downloading the feature flags. The CDN enables low latency pulls. Simultaneously, a streaming connection is set up to notify the SDK of any changes to its flags.

Why does Split incur the cost of the download up front? There are three main benefits:

  • Privacy. With the rule defintions local, the SDK can evaluate feature flags without any connection to the Split cloud. This means that private customer information – e.g. age, account balance, or credit score – will never leave their mobile phone or browser. Split doesn’t store private customer information. Other solutions ask to upload user information for evaluation on the server.
  • Performance. Split SDK can evaluate feature flags without network transactions, which makes it more resilient in the face of everyday network interruptions. If a customer walks into a parking structure and loses connectivity, your app will behave properly regardless. Split can also cache the feature flags so that repeat visits load faster than the initial.
  • Experimental integrity. Modern application are not a flat sheet. They have tabs, buttons, turny knobs and other UI controls. If your feature is under one of these controls – “under fold” – then you only want to put customers into an experiment when they’ve actually seen the feature flagged control. Server-side solutions batch evaluate users and put them all into an experiment when only a small portion may have actually seen the feature. Split SDK lets you do a live, just-in-time evaluation, yielding accurate data integrity.

Split SDK Resiliency

The client cache (e.g. local storage) allows the Split SDK to begin evaluating even when the CDN is unreachable. But in worst case scenarios, every feature flag has a “control” block it can use to provide a default treatment to the end user.

On the server-side, Split offers the ability to integrate Split SDK with Redis. The Redis cache is kept up-to-date with the latest feature flag data, courtesy a service called the Split Synchronizer. With Redis available, the SDKs are even less likely to experience an interruption, and load time drops in most cases to a few milliseconds.

The Split Proxy maintains a cache of feature flag data under control of your own infrastructure when connecting from a client-side SDK. With this approach, you don’t have to connect to sdk.split.io at all, but instead can connect to your own sdk.acme.com. Some customers even proxy to Split through their own CDN.

What is the Perfect Feature Flag?

It’s the flag that gets your job done. If you’re content to do database updates against a shared table to toggle flags, you don’t need Split. When you want to target groups of users, launch with a randomized “canary” release, or surgically target users by their private attributes, it can be helpful to have a console and a feature flagging architecture that supports it.

If you want to do experimentation, it’s even more important. The feature flag will govern experimental integrity, and then the feature data platform will harness that data to produce actionable results.

If you’re writing a sorting algorithm, you can choose between saving memory or saving computational complexity. The right choice is the best choice for your purpoes. As you think about feature flags and feature data platforms, make sure you understand your choices, what they provide and what they do not. Then you’ll make an informed decision that will serve you well.