Understanding the Difference Between Feature Flags and Remote Config

Developers adding or updating features in applications require tools to address multiple scenarios when deploying capabilities in their apps. Perhaps:

• There’s an official launch date for the next release but you need to get the feature into Alpha and Beta testers’ hands before the release.
• You’re not sure real users will even want the feature, so you want to get it out there for a subset of users to see how they react to it.
• You want to test a feature but really need access to production data and context.
• You’re not quite sure about the feature’s implementation, so you want to try multiple variants on real users to see which resonates best.

Developers have a variety of tools in their toolbox to deal with these scenarios and that means multiple ways to solve this problem. Often, dynamically enabling a product feature or capability in an application takes more than simply turning the feature on or off. Instead, you may need to deploy one or more settings to the application to configure the feature. This requirement uncovers a distinction between feature flags and remote configuration (remote config) and that’s what we’ll cover in this post.

At Flagsmith, we allow you to create features which are a feature flag (boolean), or remote configuration (a string).

What Are Feature Flags?

Feature Flags (also called Feature Toggles) are a way for development teams to instrument an application to enable or disable features under specific conditions. Martin Fowler wrote the OG article on feature flags/feature toggles, and it stands up to this day.

Developers often use simple feature flagging or feature toggling as they’re implementing new or significantly updated features, hiding them until they’re ready for anyone but Alpha or Beta users. Developers also use feature flags to enable features under certain conditions such as a random selection (like a percentage) of users, users that have specific settings, or other criteria. Feature flags give developers a simple and manageable way of delivering different experiences to users.

Feature flags enable applications to deliver completely different experiences based on a categorization or grouping of users (those who have the flag set and those who don’t). The member of your team managing the experience assigns users to groups based on existing relationship parameters or can assign them based on any trait they would like (determined from app usage, email, or manual assignment). What the user sees in the app is due to how you classified the user through feature flag assignment. You can even assign flags to a percentage of the user base, chosen randomly, and increase it over time until everyone has the feature, this is called a phased rollout or canary deployment.

With feature flagging, the system tracks the exposure of features based on the selection criteria built into the flag. With the right analytics data, you can track how long users engage with the feature, when they abandon workflows using it, and more. Flagsmith has integrations with many of the popular analytics products (Mixpanel, Amplitude), and Customer Data Platforms (Segment) – so you can automatically send this information to your preferred analytics platform for analysis.

Flagsmith customers use feature flags for a variety of use cases. To give readers a taste, we will share a few examples of how our customers use feature flags, though there are many more!

Feature Flag Use Cases

Phased Rollouts (AKA Canary Releases, Canary Deployments, or Incremental Rollouts)

One Flagsmith customer uses feature flags to swap out a major internal component of the application. Rather than build and deploy two versions of the application during the transition, they added the new capabilities to the existing app, turning on the feature for a subset of the users through a feature flag. As the ‘new’ version of the app ran, they collected data about performance and stability, then slowly completed the migration to the new technology. App users hardly even noticed it was happening.

A/B Testing (AKA A/B/n Testing or Multivariate Testing)

‍A/B/n Testing is a very common way to test users’ reaction to two or more options for a feature and use statistical analysis to pick the best performing variant. To share a creative use case, one Flagsmith customer experimented with different advertising platforms, implementing support for multiple platforms, and then using feature flags to enable a specific platform on a subset of user devices. This allowed them to deploy a single version of the app, while simultaneously A/B (or even A/B/n) testing the different platforms in real-time looking for the biggest revenue impact.

Kill Switches

Feature toggles can be used as a kill switch for a new feature release, or more creative use cases. One Flagsmith customer uses feature flags to enable LogRocket, an incident response tool, inside their application during an incident or outage to collect additional data for troubleshooting purposes. When an issue appears, they turn on the feature and watch. When the issue resolves, they disable the flag and operations go back to normal.

Feature flags aren’t perfect for every scenario. A potential drawback is that they’re binary; it’s a flag, so the flag’s either up or down (on or off). What do you do when you need more than that, for example to push data to an application? You use Remote Configuration.

Remote Config

With Remote Configuration, an application retrieves a block of application settings from somewhere (usually the app’s backend server or service), then configures features within the application based on those settings. These settings are typically hidden from users, working away in the background giving groups of users different experiences in the app. Remote configuration makes an application’s operation dynamic, giving backend operators flexibility in how different parts of the application work.

Let's look at some examples.

Remote Config Use Cases

Simplify Testing in Multiple Environments – Developers also use remote configuration to simplify testing applications in multiple execution environments (for example: integration, test, production). In this case, you deploy the app with settings configured for the production environment, but during integration testing or functional testing, you use remote config to push environment settings to testers so they run in the right environment.

Push 3rd Party API Keys

Another scenario we see is customers using remote config to push API keys into applications. If your application leverages third-party services that require API keys and the keys expire periodically, you can use remote config to push those keys to applications as needed.

Remote config provides developers with a simple way to manage a catalogue of OAuth providers for an application, as you add support for additional authorization services, merely add them to the remote config and push the settings to users.

Backend Updates – Say you’re working on an application and the application makes use of a back-end service to accomplish some task. As you tweak and tune the app’s interaction with the service, you change configuration values. Now, you can deploy these changes with an application update, but that takes time and often involves your app users. It’s much simpler to use remote configuration to deploy those application settings to a user or a group of users then watch what happens and adjust as needed. Select a subset of your application users, push the configuration to their devices, then monitor activity through collected telemetry or other means. When you need to make an adjustment, update the settings, redeploy, then rinse and repeat until it’s just right. When you’re sure of the settings, deploy them en masse through remote configuration or embed them in the next version of the app and deploy.

These first examples deliver behind-the-scenes flexibility, but there are client-facing scenarios as well…

Dynamically Changing App Content

Businesses benefit by eliminating developer involvement with dynamic client-side capabilities. Take for example scenarios where there is frequently changing content that app managers want to display to users. Developers could build a custom content management system for storing the content plus add client-side capabilities for displaying them, but another approach is to skip the custom content management system and just let Marketing or some other team deliver the content using remote configuration. Imagine a health and fitness application that regularly pushes motivational content or fitness news to user devices. With a small developer investment to display the content, if it exists within the app’s configuration, you can give responsibility for updating the content to another team using remote configuration. When there’s data to push, the team updates the remote configuration in Flagsmith and away it goes.

Notifications

Some teams use remote config to push notifications to users. When outages occur in backend systems or services, administrators can send status updates to the application via remote config. When the application sees a change come in, it can pull the message and display it to users.

Remote configuration gives developers flexibility in controlling which settings apply based on traits. These can be chosen by manual assignment (for Alpha and Beta testers, for example), randomization, app telemetry, or some other grouping methodology. Remote configuration keeps the development team from being involved in everything that happens in the app.

So, What’s the Difference?

To summarize the difference, it comes down to the type of data managed by each. Feature flags are, by their very nature, binary – they’re either on or off. Developers often use Remote configuration for managing settings that can’t be represented through a boolean. Depending on the application, the two work together to give developers or application managers more finite control over how the application operates without requiring deployment of an updated version of the application.

Fortunately for you, Flagsmith allows application managers to manage both feature flags and remote configuration. When you create a feature in Flagsmith there is an option to add a Value; leaving this blank creates a boolean flag, adding a string makes it remote config. It’s that easy!

Conclusion

Remote configuration and feature flags give developers the flexible tools they can use to tailor application experiences for their users in several situations. Your best next steps here are to think about how each approach applies to your current (or planned) applications and try it out using Flagsmith.

‍

If you want to try out Flagsmith for feature flags and remote config, just create your account here or contact us for more info.