Tom Maslen is the creator of featureflag.tech — a fully managed feature flag service that is simpler than a self hosted Open Source solution and better value than “enterprise” alternatives. Here he talks about how to get started, and compares the options on offer.
Feature flags are becoming an increasingly standard technique used in software development. It’s a powerful technique that allows you to modify the behaviour of your software without changing code.
They can be used in various ways, its important to understand what is required of them before integrating and managing them. They have become so ubiquitous that there are many different options for you to integrate them: open source projects, paid for services, some teams even build their own. I’ve been using them as part of my job as a software engineer for a few years now. I’d like to brain dump everything I’ve learned about them.
In this blog post I will explain:
- What feature flags are, how they can be used and the different kinds that are available.
- Deciding What your requirements are.
- Choosing a feature flag solution.
I’ve really grown to like feature flags, I hope once you’ve read this post you’ll be interested in using them in your existing software project.
A quick overview of feature flags
At its most basic level a feature flag is just a file — deployed separately from your code base — with a series of values in it that will allow you to branch logic from in your code. For each environment your code runs in, you’d have a different feature flag file. You can then enable and disable features depending on where you want that feature to be shown.
// Test environment
// Live environment
A feature flag will allow you to rapidly but safely deliver new functionality. By wrapping the bit of your code within a feature flag — turned off by default in your live environment — you can work directly on the master branch, commiting when you’re ready to (safe in the knowledge that your unfinished feature won’t be seen in production). No more mega branches, no more merge conflict hell. Instead of doing a big scary commit you simply switch the feature flag in your live environment. If you find an issue with the new feature, quickly disable it by switching the feature flag again.
Want to try a new version of an algorithm? Use a boolean feature flag to let your code decide whether to use the new or old version. You can then switch between these by updating the value of the flag.
You can also use a feature flag for fine control of a value. Want to be able to quickly change the distance of a new floating element from the top of a webpage? Then using a feature flag to hold that value will enable you to quickly adjust that position without a code redeploy.
Once you’re happy with the positioning, you can hard code the value into your application and remove the flag.
Feature flags are deployed seperately to your code base. They need to be hosted somewhere that allows you to quickly update them, and is available to the software project that wants to consume them.
There are more advanced uses of feature flags, but these require a different kind of feature flag. Because of this feature flags come in two flavours depending on how they are hosted:
- Static flags — typically hosted by a file that only changes when you want it to — like the examples above.
- Dynamic flags — hosted by a service that will change the value of the flag depending on what values you send with the request.
Dynamic feature flags
The examples above all involve a feature flag that changes only when you want it to. Dynamic feature flags will change based on values that you send with the request.
This is useful if you want to change a value based on an attribute of your users for example. Want to provide different values depending on where the user is from? Maybe you are implementing an A/B test and you need to randomly put users into different groups? Then send the user’s cookie id to your feature flag service.
Dynamic feature flags need to be hosted by a service rather than just a static file. Certain feature flag services will even let you choose values for each flag dependant on certain cohorts the user is in: the country they are from, values assigned to their unique ID. This is where a feature flag service starts to blend into CRM territory.
For more detailed information on the subject I’d recommend Martin Fowler’s excellent blog post Feature Toggles.
Deciding What your requirements are
So now you know what feature flags are, and hopefully you’re keen to start using them. Luckily there are many different options available to you. Unfortunately knowing which one to choose takes some thinking.
It’s best to understand what your requirements are, here is a list of concerns my team had when moving into feature flags. You should note down your answers to the following questions.
What’s your budget? If your budget is zero, then you’d think you may have to go with an open source or build your own solution. But fortunately some of the paid for services offer a free tier, however your usage will be limited. While price is normally the first thing you check for, don’t be put off by something you think is too expensive. How expensive is your free time? Think about how much time managing a feature flag service might take you.
How much time do you have for managing feature flags? While open source projects are free from a price point of view, you will need to host them yourself. If this involves a dedicated server then it is going to need to be maintained.
What are your response time requirements for a feature flag? If you’re building a web service, then you are probably sensitive to making extra HTTP requests to build your response. This means you might want feature flags that are on the same metal, or at least in the same data centre as your service.
Who will be changing feature flag values? Is it only technical staff that will change feature flags? If you have non-technical staff then you’ll probably want a control panel to help them make changes. If you are comfortable on the command line then maybe all you need is API access.
Usage (amount of requests / size of audience / number of flags and environments)
How often will you be accessing feature flags? How many do you need to set? Do you want multiple environments (dev, staging, live)? While paid for services are typically the easiest to manage, they will get more expensive the more you rely on them. Prices typically increase with scale of use. If you are requesting feature flags hundreds of times a second the price of a paid for service could quickly become very expensive.
Dynamic flags (A/B testing and cohorts)
Do you want feature flags that are the same for everyone or differ for A/B testing or for personalisation? While this is an advanced feature, its worth taking a moment to think about. I wouldn’t try to optimise for the future, so don’t make a decision based on what you think you’ll need in 12 months time (as that’s not very agile), but it’s important to understand that you may need to swap a feature flag service out for an alternative sometime in the future.
Do you want to keep a record of when flags where changed? This is useful for auditing purposes.
Choosing a feature flag solution
There are so many options for feature flags out there that its impossible to mention them all. I’ve spent a lot of time looking into them and I’ve found that you have roughly 5 routes you can go down:
- Make a simple version yourself
- Make your own advanced feature flag system
- Open source projects
- BIG open source projects (you know, “enterprise” level OS projects — technically these are distributed KV stores)
- Paid for services
Make a very simple version yourself
So here’s a secret the companies who are trying to sell you feature flags as a service don’t want you to know: building your own simple feature flag is actually very easy.
If all you need is static feature flags, and everyone in your team has the technical capability of editing and deploying a JSON file online (deployed to a service like AWS S3 for example), then that will be good enough to provide you with a “feature flag service”. This is going to be cheap, it’s not going to take you much time and you’ll be able to use it however you want (think multiple files for different projects and environments).
However FTPing a JSON file won’t give you an easy to use control panel or dynamic feature flags. You could still get an audit of changes if you store the JSON file in a repo (like Github). You may find that this low-fi approach suits all your immediate needs and you can swap it out for a more complex solution in the future. Also note that it’s going to be an extra HTTP request in your architecture.
- Uploading a JSON file to a public online URL is a legitimate low-fi “feature flag service”.
- Costs nothing more than the hosting fee.
- All flag editors need technical access to infrastructure.
- Not as easy to edit a feature flag as any of the other options.
- No advanced features.
Best for: purely technical teams who want the absolute basics of feature flags.
Build your own advanced feature flag system
My previous and current employer both developed feature flag services internally. While they had different technical implementations the purpose of both was the same. Building your own advanced feature flag service is definitely the nuclear option, it’s going to be the one that costs you the most in time and effort, but its going to do exactly what you need it to.
As you can see from the option above, feature flags are relatively basic so if your requirements are very specific going down this path could be your best bet. You could even use any of the existing open source projects as a starting point. A custom made feature flag service’s architecture and usage is going to be to your benefit.
However you will need to treat it as a proper project: hosting, supporting, data storage. Do you really want to add this much complexity into your job when you could simply pay another company to do it? With feature flag services becoming increasingly commoditised, making your own should really be a last option after you’ve looked at all the alternatives.
- Use as a last resort.
- Check all the other options first.
- If this option is chosen, think about using an existing open source project as a starting point.
- Will do exactly what you want, how you want it.
- Time vampire (in terms of production and running).
- You own it, you support it. It takes time away from the actual product you’re trying to create.
Best for: If your requirements are really that exotic then making your own from scratch or using one of the many open source projects out there as a starting point is really the only choice you have.
This is the first “open source” category. With this I’m referring to projects that are free to use, but also come with little to no support. The other “open source” category I will talk about afterwards is what I consider to be BIG or “enterprise” open source. By that I mean they are free to use, but there is a professional organisation that backs the project and you pay them for support.
There are MANY open source feature flag projects. Too many to list. They also come in a few different flavours too and are all of varying quality. While the point of entry for these projects costs you nothing, you have to host them yourselves so there is a long term cost of maintaining them.
I can’t vouch for the quality of the following services but they have been stared many times on Github and seem to have recent activity.
They all generally fall into these categories:
If you Google “feature flag [NAME OF PROGRAMMING LANGUAGE]” you’ll find an open source project. This doesn’t mean its any good or does everything you need. However you will find something.
For example Ground Control is a library specifically for Android. The feature flags are hosted directly in the app — so there is no central service or API, and are controlled directly from you the author of the app using “AFNetworking”.
Fully featured service
These have a control panel for you to (sometimes) log into, update and save each feature flag, and then via an API consume the data. This will essentially be an open source equivalent of what is offered by premium 3rd party services.
One fully featured service I can recommend is Bandiera, this is because its been developed by the very good developers of SpringerNature (my current employer) and is used internally by the company.
While these are fully functioning feature flag services, they have no control panel and are interacted with via a REST API. They will be hard to use for non technical members of your team. Examples include Feature-flags and dcdr.
- Loads of options, you’ll probably find something that meets your requirements.
- If server based, you have to maintain the hardware yourself so beware of hidden time vampire-ness.
- Quality will vary, choose carefully.
Best for: teams with more time than money and are comfortable maintaining additional services.
BIG open source (enterprisey!)
I always describe BIG or “enterprisey” open source projects as open source projects that are free to use, but there is a professional organisation that backs the project and you pay for the support. Think Redhat or PostgreSQL. Technically the following services aren’t feature flag services, they are distributed KV stores but can be used the same way as a feature flag service.
If you’re heavily into containerisation, kubernettes or PaaS (Platform as a Service) then these services are probably for you. The deployment of feature flags across your fleet means requesting feature flags won’t incur the cost of an additional HTTP request.
However dev-ops ways of working typically mean non technical team members are removed from the process, so this could slow down the time it takes to make changes and make it hard for you to keep an audit. Setting up these services is not going to be trivial either. These services aren’t really feature flag services, so you will only be able to take advantage of static feature flags.
Example services are:
- Enterprise level support provided by third party organisations.
- Local feature flags deployed across a distributed system means no additional HTTP requests in your architecture.
- Support can get expensive.
- Requires dev-ops level of understanding in your organisation.
- Access limited to technical staff.
- Dynamic feature flagging not available.
Best for: dev-ops-like teams who want the power of feature flags but without the network costs.
Paid for services
Like many other parts of a software product, feature flags can be outsourced. While this option is the most costly upfront, feature flag services will provide you with a rich UI control panel that is fully managed and won’t drain you down with maintenance issues. You’ll get the best features from all the other alternatives but at a price.
All the premium products offer a rich and easy to use UI, with user accounts, multiple projects with multiple environments so you can use their service in multiple ways. They will also provide you with a rate limited API. You should also get advanced features: A/B testing, personalisation, etc.
Premium services are trying to get you to spend as much money as possible with them, so their usage will be tiered. It’s important to look at the pricing structure, make sure the usage you require won’t cost you too much. Questions you need to ask yourself are: do you need to support many projects and environments? Do you need multiple user accounts? How many end users does your application support?
For example Launch Darkly pricing starts at $79 per month and that will give you a single user account to access two projects which both have two environments each. You’ll also be limited to 10,000 unique users per month. Unlimited access will set you back $699 per month. An “enterprisey” alternative to Launch Darkly is Rollout.io who don’t actually publish their pricing model, this makes me feel they are expensive.
One last thing to note is another potential negative for 3rd party premium feature flag services: they are hosted outside of your infrastructure, so calling these services will increase the response times of your service.
- Fully featured.
- Easy for everyone to use.
- No maintenance overhead.
- Monthly bills.
- High usage equals higher monthly bills.
- Additional network request in your architecture.
Best for: if money is no object and you want the easiest and most powerful use of feature flags, this is your option.
Hopefully you’ve found this blog post useful. I’ve tried to put everything I know about using feature flags into this one post. The parallels between the first option I spoke about — FTPing a JSON file to a public URL — and the last option — paying a premium price for a service to do it for you — is actually quite funny.
While the paid for services are very good and they do everything you could ever wish for, when it comes to static feature flags I feel they are very expensive. You’re essentially paying to edit a JSON file and host it online, this shouldn’t cost much more than their actual hosting fees.
This is why I’ve created my own premium feature flag service —featureflag.tech. You’ll get all the same features but the pricing model is based on usage. You can create as many users as you like, you can create an unlimited number of projects and environments. The pricing is tiered by how much you use it, with a free tier up to 43,800 requests per month, over that it costs $4.50 for up to 2,592,000 requests per month.
Featureflag.tech is based on cloud infrastructure, so its super reliable and I’m only charged when you use it. With a modest % added on top of our monthly costs, I’d hope you’d find our pricing model to be very fair.