In a previous post, we discussed the pros and cons of building your own feature flag management system versus buying a commercial, off-the-shelf solution. If you fall into the former camp and have built something internally, how do you know when you've outgrown that solution?
As your organization scales, you'll inevitably outgrow tools and solutions. This doesn't mean you made the wrong decision to build something. It just means you've grown.
As companies expand, their needs change. For instance, what once made sense as a side project for an individual contributor may no longer be feasible for a single person to support.
This article will help you determine whether or not you've outgrown your in-house feature flag management system and if it's time to explore alternatives.
How has your application changed?
Companies typically use multiple languages in their applications. Can your solution adapt to the addition of new programming languages in the application stack? How many languages do you need to support? What are your plans to add support for more languages?
Is there a need to run client-side vs. server-side? Client-side flag evaluations and data can provide useful information for targeting or running experiments, but it also increases security concerns, risk, and complexity. Opening connections from the client-side resource to the server requires authorization and implementation of security measures. If your user base is geographically diverse, a content delivery network (CDN) may be needed to help with latency.
How will you support multiple use cases across multiple teams?
When you started, a single team was probably using a handful of flags to separate deploys from releases.
Now, other departments want to create feature flags. Operations and site reliability engineers (SREs) want to use flags as circuit breakers and for load-shedding. Product managers want to run experiments. Sales and customer support want to manage entitlements. These new use cases require access control and permissions for safety and security purposes. They need additional functionality.
Operations needs:
- Audit logs to see flag changes across the organization—who made the change, when the change was made, and why.
- Integrations with existing tools to toggle flags programmatically or kickoff other workflows.
For example:
- When performance thresholds are passed, certain flags should be toggled to deliver a lighter version of the page.
- Adjust logging levels programmatically when an alert is received.
- Multivariate flags to define multiple options that a flag will serve for running experiments.
- Advanced targeting rules to control who does or does not have access to certain features. This includes creating segments and target groups based on specific attributes.
- Flag prerequisites and relationships to control groups of features.
Customer Support needs:
- Troubleshooting tools to know which variation a user was served to troubleshoot issues.
All teams eventually need:
- Access control logs to restrict access to their team's flags and ensure only authorized people can toggle a flag on or off. Can you run the risk of somebody editing a configuration file and accidentally deleting a flag?
- Reporting and insights on the flags served. What percentage of users has the feature been rolled out to? How are targeting rules or new variations impacting the number of evaluations?
- An intuitive user interface to toggle flags on and off. You don't want to give everybody access to a config file or a database. Other departments will require a user interface to control and configure their flags.
- A solution that scales with increased page views and greater numbers of flags being toggled.
- An organization-wide dashboard to display the flags, what's enabled, a flag's purpose, and a point of contact for each flag. This helps control technical debt and manage the use of flags across the organization.
How will you support multiple feature flag systems?
If you have multiple languages to support, you may need to deploy multiple solutions as they are often language-specific. Without centralized feature management, different teams may build or deploy a solution that meets their business needs. How many feature flagging systems is your organization able to maintain?
Given that many feature flagging tools are language-specific (see table below), the more languages your application uses, the more tools you'll need to support it. In addition, other teams may choose to implement solutions to meet their experimentation or testing use cases. The more solutions you have with similar functionality, the more confusing it is to those supporting and configuring them.
Is maintaining an in-house feature flagging tool worth your time?
According to the 2019 State of DevOps Report, elite software teams use a combination of proprietary tools, open source, and commercial off-the-shelf software. Low performers have the highest concentration of proprietary software. While there is value in building your own tools, it comes at a cost.
When you made the decision to build vs. buy, it made sense to divert your engineers from building core product features to build and support the internal feature flagging tool. Now, it is time to re-examine those decisions. Ask yourself again, “Can I afford to divert engineers from building core features to build features for our internal feature flagging tool?” Times have changed; that answer may be different now.
From the time you decided to build your own feature flagging system to now, your company has grown in size, and customers are requesting more features. You need more engineers to keep up with this rising demand.
Do you want those engineers to devote all their time to maintaining an in-house feature flagging tool, or would you rather have them creating new stuff that drives revenue? Will investing in this tool hold you back from meeting your quarterly or yearly goals?
If you aren't in the business of feature management, devoting valuable time, resources, and people to supporting internal tools may no longer be in the company's best interest. Some of our best customers originally built an internal solution and later decided to buy, allowing them to focus on what they do best.
How will you scale?
Feature flags should be lightweight. Adding flags should not result in exceeding performance budgets and breached service level agreements. What is the acceptable latency of a flag triggering, and how can you deliver this at scale (see the point on CDNs above)? What infrastructure is needed to ensure system reliability, and what is the cost of that infrastructure?
When the system was originally designed, did you opt for a pushing or a polling architecture? Will that scale, is it worth it to re-architect the system? As more flags are added to the application, the size of the payload sent to the user increases. Larger payloads can result in poor performance or delays with flags propagating to users. Building a robust infrastructure to support feature flagging on a larger scale can be an expensive undertaking.
What to do next
Growth is good. If you've outgrown your internal solution whether due to expanded use cases or wanting greater control over the release process, it is time to invest in a commercial solution. Using the requirements above, determine your must-have features to help you select the best feature management platform for your organization.
If you've decided it's time to migrate off your homegrown solution, be sure to check out our third installment of our “build vs. buy” blog post series. We'll walk you through the ins and outs of migrating to a commercial feature management platform like LaunchDarkly.
If you're considering ditching your homegrown feature flag solution and switching to LaunchDarkly, this guide will tell you why that's the right call.
.webp)
