Credit: Dreamstime
Most developers no longer work in rigorous waterfall development cycles, in which a major release consisting of a set of features is planned six months in advance and then deployed to test and QA before finally being deployed on prod.
That rarely ever worked. Waterfall was like selling record albums versus just delivering a new song to stream whenever you think you have a hit.
In cloud organisations, teams work on individual features and deploy many times per month. Some places have multiple deployments per day. As these teams focus on cranking out the “hits,” many are now using feature flags to manage which features are enabled, where they are enabled, and for whom.
What is a feature flag?
So what is a feature flag? “It’s effectively an if statement, which has been around as long as we’ve been writing code. So it’s not new, it’s structured in a way that you can control it,” says Jim Schuchart, vice president of software delivery automation at CloudBees.
“At the heart of it, feature flags allow you to decouple a deploy from a release,” Schuchart explains. “So in a world where you don’t have a feature flag in your code: I deployed to production, and I released to my customers, and that is the same thing.”
When rolling out a new feature, one may not want every user to get the feature simultaneously. By deploying to a smaller set of users, you can ensure the feature works before setting it upon the world. According to Lawrence Bruhmuller, CTO of Optimizely, “There’s a big movement around testing in production because nothing is like production. Attempts to get a staging environment that is very production-like is a lot of effort, and you never really get it right.”
In a heavily used cloud application, it is possible to gather data on how users interact with a feature. For instance, when Airbnb rolls out new performance reporting tools for hosts, they could see who uses them and compare that to the previous tools.
Analysing whether users interact more with the old version or the new version of a component is essentially an A/B test, which marketing professionals have used since time immemorial for content.
Another use of feature flags is entitlements. According to Alea Abed, senior product marketing manager at LaunchDarkly, “You could enable your sales team or your support team to give customers certain functionality based on an issue they’re having or an upgrade to a different tier.” Meaning your support reps could flip on the “pro” or “enterprise” version of your software by toggling a flag.
Feature flag management and maintenance
The biggest problem with feature flags is that they can get left in the code, leaving you with so-called “technical debt.” Talia Nassi, developer advocate at Split, suggests that maintaining feature flags follows a lifecycle.
“There’s four parts,” she says, “there’s creation, implementation, rollout, and cleanup.” Essentially your team needs a policy about when feature flags are cleaned up and who is responsible for the flag. Nassi suggests that establishing ownership is vital to feature flag hygiene.
According to Jon Collins, vice president of research at Gigaom, current tools are not up to the task of unbounded complexity.
“The trouble is you don’t stop at a B testing, you want to do ABCD testing,” Collins says. “Nothing ever stops at simple. A lot of the tools that we have these days are good, as long as you don’t try and push them too far. Once complexity comes in, the tools can’t cope with it.”
Many cloud-based organisations develop their own custom feature flag kits and then later move to a product or service when they become unwieldy. All of the vendor offerings have SDKs for popular languages. Most of the SDKs are open source.
As opposed to “if statements,” the SDKs hook into monitoring and management capabilities of feature flag platforms. Some of the feature flag offerings have inexpensive or free “starter” tiers that do not cost you anything until your application starts handling volume.
Who are the major players
The major vendors in this area are CloudBees, LaunchDarkly, Optimizely, and Split. Their history and focus differentiate their products.
CloudBees has a storied history but has been in the Jenkins and continuous integration game for nearly a decade. Their feature flag support is an outgrowth of this business. They see a focus on developers as a key differentiator along with a security focus.
According to Jim Schuchart, “A large part of our security model is based on the fact that we receive very little of your data. Like the bare minimum,” he says. “Everything is processed locally, which has great speed advantages, but it also has great security advantages.”
LaunchDarkly is the name to beat among feature flag implementations. They see their developer focus and product focus on feature flags as core differentiators. According to Abed, “We really focus on the developer. And we’re starting to look at how product teams can use feature flags. A lot of the competitors are one-size tool fits all.”
Optimizely started with a focus on A/B testing and experimentation for a non-technical user. According to Bruhmuller, “I think we come from this real position of strength in having done A/B testing experimentation for a long time, and kind of started it.” But their having done it earlier isn’t the only reason to go to Optimizely. Optimizely also incorporates a statistical package and ensures data scientists can extract data for their own tools.
Split also sees its developer focus as critical, as well as its integrations with other tools. “Split is super developer-friendly,” says Nassi. “We have a ton of SDKs, and we have tutorials on how to use all the SDKs.” Split also prominently advertises their analytics capabilities.
What’s next in feature management
Feature flags and the associated tooling are just part of an overall transition from “release management” to “feature management.” Essentially this is a sign that the nature of software development is changing. As microservice architecture took over from monolithic software development practices, it makes sense that delivery and deployment would match this change.
GigaOm’s Jon Collins suggests that the feature management approach sees features and feature delivery from a product management mindset rather than a project management mindset. According to Collins,
There’s a huge overlap between what feature management needs to do and what value stream management is already doing. Around just identifying the flow of things through the pipeline. If you look at IBM’s UrbanCode Velocity, for example, there are really nice graphics, you see the little circles moving through, and then you see them stuck. And then you can drill into why they’re stuck, and how long they’ve been stuck, and they change colour. So that kind of visualisation, but as an approach to... so we don’t need to manage features so much as manage units of delivery, which we can call features. And it becomes all about throughput, which is one of the original precepts of DevOps.
The effect of this form of feature development may evolve our entire development and release engineering process. Rather than plan numeric releases, features are deployed to production as separate workstreams and deployed as they are ready. From there, they are rolled out to users and “tested.”
It is conceivable that it might even affect our pricing and development priorities. Rather than selling a user a subscription to your service or application as a monolithic whole, you sell them specific features. The features that sell well get priority, and those that users do not like simply starve after an initial investment period. Again, we are talking about individual songs (features) rather than albums (releases).
