At Trajectory, Speakers Argue for Improved Feature Flags
The numerous benefits feature flags offer have existed for years. However, today’s DevOps teams demand a greater reach from feature flags than in the past, as new challenges associated with releasing software have emerged.
In short, according to several speakers on Tuesday and Wednesday at LaunchDarkly‘s annual user conference, Trajectory, feature flags need serious improvement.
As deploying applications at scale across multicloud and on-premises environments become more common, the associated complexities and the pressure to boost release cadences are just two examples of today’s challenges.
Deployments at scale, especially those that support large migrations, also mean that the consequences of failed deployment are potentially that much greater. This context has set the stage for even more fear and dread for when releases might go horribly wrong.
@weavework‘s @futurile:”We actually know less about how to run things now than we did years ago. As in, we’re now running hundreds of services that are put together to create services that just add complexity.” @Launchdarkly @thenewstack https://t.co/lXR7NlWTxf #TrajectoryConf pic.twitter.com/IXZmrAPi8G
— BC Gain (@bcamerongain) November 10, 2021
Teams Want Tighter Control of Feature Flags
Today, several speakers at Trajectory emphasized, feature flags must offer DevOps teams — among other things — tighter and more direct control of how application features are activated, deactivated and released in stages.
Representatives from LaunchDarkly — which has an obvious vested interest in the use of these tools, as a leading feature flag provider — articulated what is at stake during Trajectory.
During her conference talk, Edith Harbaugh, LaunchDarkly’s CEO and co-founder, discussed a Gartner report that showed how the vast majority of deployments fail and why that does not have to be the case. Feature flags that are better adapted to today’s multicloud release challenges, as she described during her talk, have been shown to significantly reduce release failure rates.
Forget crash and burn releases: “Feature flags” are used to deploy code in production without fully releasing it. By separating out deploy from release, features can be only gradually released to any segment of users, @launchdarkly CEO @edith_h. @thenewstack #TrajectoryConf pic.twitter.com/QWTxb7OcNc
— BC Gain (@bcamerongain) November 9, 2021
“In the cloud era, infrastructure is so tightly coupled with delivering first-class customer experiences that we can start to think about all components of our application as features,” said Harbaugh.
“Our ultimate goal is to ship value to users in a more effective way. Whether that’s [for the UI] or the database on the backend, feature management helps us get there. So when we think about progressively releasing a feature, think about it as a set of stages.”
Top Reasons to Adopt Feature Flags
Risk mitigation and deployment stability were the top-cited reasons DevOps teams use feature flags, according to the results of a report LaunchDarkly released in early November with Wakefield Research:
- For LaunchDarkly customers who participated in the survey, the top three reasons to adopt feature flags (in order) are risk mitigation, deployment stability and beta-program management.
- Non-LaunchDarkly users say their biggest reasons for flagging are (in order) deployment stability, risk mitigation and a tie between running A/B tests and measuring user acceptance.
@RelativityHQ‘s Dan Wells described how visibility and control were required to support 80 applications and 50 teams. “We knew we couldn’t do a big bang migration..We needed to do it very incrementally,” he said. @Launchdarkly @thenewstack #TrajectoryConf @thenewstack pic.twitter.com/6WMKhvn9jV
— BC Gain (@bcamerongain) November 10, 2021
As one of the users of LaunchDarkly’s self-reported “20 trillion flags daily,” unstructured-data SaaS provider Relativity recently upgraded the feature flags for the software platform that it offers its developer customers. Relativity customers, which include law firms and global corporations, have unstructured data problems associated with legal compliance and privacy, said Dan Wells, a technical architect and software engineer from the firm, during his conference talk.
The feature flags Relativity began to offer more than five years ago have been upgraded for today’s complex needs, Wells said. “We started a feature system based on homegrown SQL databases,” he said. “It worked for a long time for us, but we wanted something more sophisticated.”
The feature flag capabilities from LaunchDarkly that Relativity adopted helped the organization complete a major migration safely, Wells said.
“We knew we couldn’t do a big-bang migration and interrupt teams and be disrupted with customers — we needed to do it very incrementally,” he said. “We needed to do it safely, where we could have rollback capabilities in case something went wrong. We needed really great tracking of visibility and control because we had 80 applications and 50 teams to coordinate.”
Feature Flags and Observability
Three years ago, Charity Majors, co-founder and chief technology officer of Honeycomb.io, a leading observability platform provider, said feature flags allowed DevOps teams to not “send anyone to this code until I say so.”
Flash forward to this week’s conference, when her Honeycomb colleague, Liz Fong-Jones described during her talk how Honeycomb uses LaunchDarkly “every day” to decouple a deployment from a release of software.
“We have a section of our pull request template that includes things like, what are the feature flags we are using and what’s our observability plan,” said Fong-Jones, Honeycomb’s principal developer advocate.
Fighting Deployment Fears
Meanwhile, the use of feature flags is one way to help remove the very common fear of failure when releasing software, especially with major releases, said Gene Kim, author of the fabled book “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”.
Describing feature flagging as “an architectural breakthrough,” Kim offered ways DevOps teams can use the right tools, such as feature flags, to help ward off that sense of dread of failure before software is released.
“My advice would be to go seek out where people are afraid to do deployments and truly understand why,” Kim said. “I think it will take you to great places and having a whole bunch of people say, ‘Thank you, for allowing us to hold your beer.’”