Feature flags done right with the OpenFeature initiative and Dynatrace

Fast becoming a staple practice in CI/CD workflows, feature flags make it easy for developers to turn features on and off like a switch. This gives them the flexibility to test, selectively release, and roll back features on a granular scale without disrupting the mainstream code base. But homegrown efforts result in technical debt and observability issues that require a standardized approach. OpenFeature is the open standard that, coupled with Dynatrace software intelligence, makes it easy to integrate feature flagging into your cloud automation regime.

In software development, feature flags are an established path to rapid value, continuous progressive delivery, and safe deployments. The ability to isolate certain software capabilities makes it easier to test, preview, release, and roll back small functional increments. Used by organizations for everything from assigning support tickets to managing failover regimes, feature flags enable DevOps teams to release software faster and more reliably.

But feature flagging can also introduce some issues. In addition to requiring a high degree of custom coding, feature flags can rapidly accrue technical debt that can be opaque to diagnose.

In this post, I’ll explain why Dynatrace and others started the OpenFeature initiative to address these issues and donated it to the Cloud Native Computing Foundation (CNCF) to make feature flagging an open standard.

Prefer to watch than read? Watch “Feature flagging done right with OpenFeature and Dynatrace”

What are feature flags?

Feature flags are a software development methodology that enables developers to turn on or off specific functions at runtime. Using scripting tags, feature flags work without having to deploy new code. This approach gives teams a high degree of flexibility and control over testing, beta releases, access privileges, and feature lifecycles.

Feature flags work by building dedicated feature branches into code that make functionality available to certain user groups simultaneously. Also referred to as toggles, feature flags enable development teams to test new features in production with minimal risk. They’re also useful for canary releases, where teams can throw a kill switch to effectively roll back a faulty feature.

Because of their flexibility, feature flags have become a staple practice for CI/CD workflows.

What is the OpenFeature initiative?

The OpenFeature initiative is an open standard CNCF sandbox project for managing feature flags. Submitted by Dynatrace and a consortium of feature flag management solutions, OpenFeature provides a future-proof, vendor-neutral way to integrate feature flagging and management solutions. Because it’s open source, OpenFeature eliminates the need for organizations to build their own proprietary SDKs and APIs. This open source approach to managing feature flags simplifies and accelerates release cycles and enables teams to automate releases at scale.

The problems with feature flags—and their solutions

The most common route into feature flagging starts with a company building its own in-house solution. A homegrown solution meets requirements and works great—until it doesn’t. Inevitably, the company realizes that their solution can’t compete with the established open source or vendor solutions, or they realize they can’t devote the time and resources to maintain their solution.

The company needs and wants to move toward a “better fit” solution, but they run into a couple of problems.

Problem #1: Tight coupling and technical debt

For organizations on the do-it-yourself journey, developers often integrate their applications directly with the in-house feature flag solution. Nothing wrong with that, until they try to move. They have tightly coupled the application logic to the feature flag “vendor” (in this case, their in-house solution).

In other words, their application is now entirely dependent on their in-house solution. They have introduced technical debt, making it costly and time-consuming to migrate to a “better fit” solution.

Problem #2: Feature flag observability

Companies use feature flags for various reasons, which all boil down to increased business agility, including the following abilities:

• Enable and disable a feature at the flick of a switch.
• Deploy code without releasing it to end users such as new functionality hidden by default behind a feature flag.
• Employ a kill switch, for example, to detect a DDOS attack and automatically enable static content.
• Experiment and run hypothesis-driven experimentation with real users.

However, knowing that a flag is enabled does not tell the whole story. Teams need crucial context to understand the significance of these data points, such as the following:

• What impact did that flag have on users?
• Were conversion goals impacted?
• Were SRE metrics impacted, such as response time, availability and throughput?

In short, businesses need comprehensive observability of the impact their feature flagging decisions so they can make data and evidence-driven decisions. make data and evidence-driven decisions.

Solution: The OpenFeature initiative

OpenFeature solves these problems. Much like OpenTelemetry, OpenFeature is a vendor-neutral specification rather than a product.

Solution #1: Increase flexibility and remove technical debt

First, the OpenFeature initiative defines a standardized method to interact with feature flag backends. Developers don’t need to worry about the feature flag backend: get_flag_string_value(“name”, “default”) is the same regardless of whether the value is coming from an in-house solution or a vendor solution.

Crucially, if the back-end flag provider needs to change, for example, from in-house to vendor, no technical debt exists, and none of the application code needs to change.

The only component that needs change is the OpenFeature Provider (marked in blue).

Solution #2: Observable by default

OpenFeature comes with OpenTelemetry-based observability by default. OpenTelemetry-compliant observability platforms like Dynatrace can easily consume that data. With comprehensive, AI-driven analysis of observability data, organizations can automatically gain answers to the impact of feature flag statuses and the services they touch. This insight helps teams make critical decisions about what to do and what to automate.

The following Dynatrace dashboard is automatically created by the Dynatrace open source monitoring-as-code standard Monaco as a result of following the hands-on example.

Who writes the feature flags’ translation-layer providers?

Providers are a crucial part of the OpenFeature initiative that translates the OpenFeature “generic” calls and map them to vendor-specific feature flag calls. They’re the middleware, the glue, the translation layer.

The good news is most feature flag vendors have already committed to supporting OpenFeature, so they have already written and maintain providers you can use. No code for you to write. For example, here are the JavaScript providers.

If your feature flag vendor does not yet support the OpenFeature initiative in your language, speak to them about supporting supporting it.

If you need to implement a provider for an in-house solution, the OpenFeature Providers page contains a how-to guide, code samples, and a checklist to get you started.

Explore the OpenFeature initiative further

Here are some ways you can learn more about OpenFeature.

• See OpenFeature adopters and interested parties (hint: add yourself)
• Watch the Feature Flagging Done Right Observability Clinic
• Explore OpenFeature
• Find OpenFeature providers in your language:
  • .NET
  • Golang
  • Java
  • JavaScript
  • PHP
• Experience OpenFeature with Dynatrace.
  • Sign up for Dynatrace free trial (or bring your own tenant)
  • Follow the OpenFeature + Dynatrace instructions
• Experience an OpenTelemetry-based in-browser demo of OpenFeature