Feature flags based development is actually nothing new. It’s a development strategy that fell from grace somewhat but is now regaining popularity and has been widely adopted at Google, Facebook, and Amazon.
Feature flags or feature toggles once had their poor reputation because of the complexity they can introduce to the code. However, using the right tools can mitigate this risk. In the May 2020 Technology Radar, ThoughtWorks recommends adopting the feature toggles in the simplest possible form. The list of potential benefits and use cases is quite long and here are just a few examples.
You can imagine the situation in which a new feature is waiting for all the other services to be deployed before it can be made available to users. This is actually one of the important downsides of microservices-based architecture. Introducing new features can be complex as it requires the deployment of dependent services at once. When these are managed by separate teams with different roadmaps, it gets tough.
Feature flags that can simplify this dependency chain a lot. As soon as all the microservices are ready to go, the versions with the right flag can just be turned on. The new configuration is then deployed and all the services respond to this change accordingly.
In eCommerce, AB testing makes a lot of sense as the Conversion Rate from customer visits is the easiest parameter to track and compare between user sessions. If you run a few different versions of the product page and category page, you can figure out which version converts better.
Feature flags managed by platforms like LaunchDarkly or Firebase remote-config can be used to program even complex business logic for switching the flags on and off. The config is then cached, distributed via CDN, and provided as a JSON file to your native or web applications. If you mark the user segments in the Analytics API, you can easily track which segment converts better.
Soft launches, beta testing, or just testing new features on a number of clients on production are always great ideas before full-scale deployment. Sometimes, it’s called a Canary Release. With feature toggles, you can control your CDN or Proxy service (Varnish, nginx, or any other that’s open for scripting) and set how many users are designated to see the new version of the app or website and how many will see the legacy version.
Serverless functions (deployed to Amazon Lambda for example) are also a great way to manage feature flags. They can contain a custom business logic used to figure out the config values and to control the experiments.
Feature flags are a great way to experiment on production, to sync services, and actually control the application. This is particularly true in a distributed environment. I suggest using a structuralized way of managing the toggles – for example, by using the Firebase remote-config.
You can read success stories of using feature toggles on Instagram and Google.
If you’re worried about how this “conditional development” might prevent your team from following best OOP principles, there is a whole set of design patterns (including Factory and Strategy) that can be used across the codebase to separate the feature flags management from the actual business logic in the code. Using the standardized platform and the config data format will let you control all the services, no matter the programming language or the framework they were built with.