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 during a rollout 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 during software development.
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 with integrations that can be utilized across multiple parts of their apps and infrastructure in a consistent way, so they build or buy a dedicated feature flag service. This takes the pressure of in-house development teams to create and config their own service on the backend.
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 flagging platform.
Feature Flags as a Service: Superior to In-House Solutions
Feature Flags as a Service platforms often provide a superior solution to in-house feature flag implementations due to their robust SDKs and APIs, which are designed for scalability, reliability, and ease of use. Here’s why:
- SDK Integration: FFaaS offer SDKs tailored for a wide range of programming languages and frameworks. These SDKs simplify the process of integrating feature flags into your application by providing ready-to-use code snippets and functions. This reduces the development time and effort required to implement and manage feature flags, as compared to building and maintaining this functionality in-house.
- API Flexibility: FFaaS come with comprehensive APIs that allow you to dynamically manage feature flags, user segments, and flag evaluations outside the confines of your application’s code. This means you can update feature flags without deploying new code, enabling faster response to issues or opportunities. An in-house solution would require additional development to achieve similar levels of flexibility and control.
- Scalability and Performance: FFaaS are built to handle a high volume of flag evaluations with minimal latency, ensuring that your application can scale without impacting user experience. Leveraging the infrastructure of a FFaaS provider can be more cost-effective and less resource-intensive than scaling an in-house solution, which would require significant engineering work to ensure performance and reliability at scale.
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 (like those in github) 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 in their development process. 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 (code deployment), 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. This also allows for canary releases, CI/CD and other best practices.
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 lifecycle. 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 end users. New features or specific features can be toggled on for internal pre-production or external beta testing while remaining invisible to everyone else. In canary releases, new features can be toggled on for a subset of users before rolling our to the entire user base. 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 by catching them in the production environment.
Feature Experimentation and Customer Experience
Once behind feature flags, new code for feature rollouts 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!
Switch It On With Split
The Split Feature Data Platform™ gives engineering and product managers the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Schedule a demo to learn more.
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.