Why do you need feature flags as a service? Why build or buy a robust solution when you could just implement a simple toggling mechanism as a one-off and be done with it? Great question! The answer? Because you would reap far fewer benefits while paying a higher price in technical debt.
Feature flag usage by development, product, and operations teams is taking off, and with good reason. The ability to decouple deployment from release and achieve fine-grained control of when new code gets exposed and to who allows teams to move faster with less risk.
At first glance, feature flags (also known as feature toggles) are quite simple: you just need a way to control the outcome of a conditional statement without doing a new deployment.
Why have a separate service for something as “simple” as evaluating a conditional statement at runtime? Because the highest value use cases for feature flags and the realities of multiple teams and multiple stakeholders getting value from those use cases aren’t easily satisfied by the first-generation DIY tactics. Let’s look at the typical journey from adopting feature flags to getting full value from them.
A Journey of a Thousand Miles Begins With a Single Step
Teams that build their own feature flagging framework often begin by adapting existing in-house tools, for instance by adding columns for each flag to a user profile table, or leveraging zookeeper or another distributed configuration store. Eventually, when they want something scalable that can be utilized across multiple parts of their apps and infrastructure in a consistent way, they build or buy a dedicated feature flag service.
Feature Flags as a Service: This Isn’t About Build vs Buy
This post isn’t about doing the math of “build vs buy” for feature flags. If you are looking for that, I can recommend Top 10 Challenges When Building a Feature Flagging Solution from the Ground Up by Lenore Adam. What I do want to cover here are the reasons why you should look beyond the simple use case before you allow yourself to become dependent on a simplistic in-house MVP.
Feature Branching vs Feature Flags
As engineering teams and product teams evolve their feature release processes, many choose to move beyond long-lived feature branches and infrequent merges to short-lived feature branches (or full-on trunk-based development) using feature flags. Why? To escape “merge hell” — longer-lived feature branches often mean painful and time-consuming merges with the main trunk down the road. Merging more often (ideally once per day or more often) becomes a much easier choice once you have feature flags to prevent the execution of unfinished features.
The related idea of branching by abstraction (placing an abstraction layer between consumers and providers of functionality and then using feature flags to manage whether old or new code is used for each request) allows gradual cut-over from legacy code to new code. Branching by abstraction makes it easier for organizations to shift from large, monolithic releases to releasing new versions and features as microservices using continuous delivery. Curious about that? Check out Manage Your Monolith Breakup by Pete Hodgson.
Can You Safely Push Incomplete Features to Production Without Feature Flags as a Service to Keep Track of it All?
As your organization transitions to continuous delivery, building and testing of new code will begin to occur more frequently, often several times daily. Putting new features under feature flags becomes critical since incomplete features will be included in every deployment at that point. We need them to be inactive so we don’t inadvertently release them to users.
Feature Flags “Cost” Less With Feature Flags as a Service: Life is Better With Tools to Track and Manage Technical Debt
As I mentioned earlier, many companies begin using feature flags as simple configuration settings, requiring an engineer to toggle the flag on or off. Without a good system in place to track and manage them, old or outdated features can begin to pile up in the code. If the person or team responsible for the feature leaves the company or gets reassigned, technical debt can linger for long periods of time, even cause problems with new features that can be difficult to diagnose.
Feature flags deliver huge benefits, but many of those gains can be lost by costly technical debt that will slow you down if you don’t build or buy tooling to stay in control of the feature flag lifecyle. Having a well-developed feature management system in place to monitor feature flag ownership, monitoring and retirement is key to platform stability, DevOps efficiency, and overall success.
A/B Testing, Multivariate Testing, and Testing in Production: More Reasons to Build or Buy Feature Flags as a Service
One of the most powerful capabilities of feature flags is the ability to toggle new features on or off to targeted segments of users. New features can be toggled on for internal pre-production or external beta testing while remaining invisible to everyone else. That use case is coming to be called “testing in production” and as scary as it might sound, it’s actually a solid strategy for improving your productivity and reducing customer-impacting incidents.
Feature Experimentation and Customer Experience
Once behind feature flags, new code can then be targeted to specific groups of users based on endpoints, physical locations, even demographics. New features can be targeted, released, and rolled back dynamically for segments of your userbase in real-time. You can perform feature experimentation and collect rich product analytics based on any number of criteria. Companies building an in-house feature flag solution may not have the time, resources or experience to create a feature flag management system to meet those needs.
A Kill Switch With Access Control and an Audit Trail
One of the benefits of a mature feature flag service implementation platform is having a well-defined kill switch, or the ability to instantly deactivate a feature globally or for specific user segments. If a feature isn’t performing as expected or causes unforeseen problems, deactivating it is as simple as flipping a switch. That’s super helpful, and it’s also a lot of power in one place, which is why eventually you will want access control and an audit log tied to it.
Better Product Decisions Through Analytics
One of the biggest challenges we all face when building in-house is setting aside the time and resources for a solid UI and reporting. It so rarely makes the cut! The thing is, a sophisticated UI for feature flag management is exactly what you need to take advantage of the more powerful use cases.
There is huge power in being able to view feature impact dynamically in real-time, monitoring engineering and business metrics to make better product decisions as you test and experiment with new features. If a feature performs better or worse with certain endpoints or even during certain times of day, that data will help you to decide how to proceed with feature release or rollback and know instantly how customer experience is affected by those decisions. Without a sophisticated UI, that approach requires a war-room like combination of many specialists who could be adding value in more novel ways.
A robust feature flagging service can help your company make the most of continuous delivery, well beyond the simple use case of decoupling deploy from release. It’s fine to start simple but don’t lose sight of the higher value use cases that will eventually require a sophisticated platform approach.
Learn More About Feature Flags as a Service
- Check out the way Walmart Labs uses the service it built to speed innovation and reduce risk in Know Your Why: Experimentation and Progressive Delivery at Walmart Grocery
- For more on the use cases that feature flags as a service make possible, have a look at my piece on the Top Three Feature Flag Use Cases.
- Curious how Split implements feature flags as a service? Check out the Introduction & getting started section of the Split docs.
Be sure to follow us on Twitter @splitsoftware, and subscribe to our YouTube channel!