How OpenFeature — and feature flag standardization — enables high-quality continuous software delivery

Earlier this year, Dynatrace announced its involvement in the open source feature flagging project OpenFeature that enables fast-paced, high-quality software development. Since then, the Cloud Native Computing Foundation (CNCF) has accepted OpenFeature as a sandbox project. With the support of many of the top feature flag companies and practitioners, OpenFeature has developed a vendor-neutral specification, and its software development kits (SDKs) for Java, JavaScript, .NET, and Go SDKs are now generally available as a 1.0 release.

Why do organizations need feature flags?

Organizations need to release software at a high velocity to stay competitive as the pace of business accelerates, but they can’t sacrifice software quality for speed. Agile companies that adopt continuous software delivery have increasingly enlisted feature flagging to enable more frequent code releases. Additionally, the open source and cloud-native communities have continued to develop open standards to ease communication between cloud-native tools and promote interoperability between vendors.

What is a feature flag?

In its simplest form, a feature flag is a toggle (switch) in an application that turns functionality on or off at runtime without deploying new code.

Feature flagging has been around for many years but has recently gained popularity, largely because companies need to innovate as quickly as possible. Feature flags support the rapid development of software features by allowing teams to decouple feature releases from deployments. Using feature flags, developers can test an unreleased feature by enabling access to it for a specific user, department, company, or any other desired unit. This allows new features to be safely tested in any environment, including production.

As companies become more comfortable with feature flags, they’re using them for more than just rolling out new features. For example, teams use feature flagging for hypothesis-driven development and experimentation, which are now an essential part of the development lifecycle. Many feature flag tools and vendors support multivariant feature flags—companies can assign users to feature variants that are determined by any available factor (for example, company, geography, or timestamp) or pseudo-randomly. Teams can then measure the impacts and make data-driven decisions.

What is OpenFeature and why should organizations use it?

A common first step into feature flagging is typically a homegrown solution. However, custom-built tools require maintenance and support, which can be burdensome for teams and can limit the growth of these internal tools. Commercial solutions provide maintenance and support; however, both homegrown and commercial solutions can present interoperability challenges that complicate future requirements.

OpenFeature is an open source, vendor-agnostic feature-flagging application programming interface (API) that allows teams to start using feature flags quickly and confidently. It works with your preferred feature-flag management vendor or custom-built tool. As a result, teams can flexibly choose a feature flagging method that fits their current requirements while being able to switch easily to a different method if requirements change.

OpenFeature users can benefit from an ever-growing community of feature flag experts. The OpenFeature community pools the expertise of many top feature flag companies to develop open solutions to topics relevant to feature flagging, including an OpenTelemetry integration.

What does OpenFeature mean for observability?

Given the large number of vendors in the feature flag market, it’s impossible for observability vendors to support all vendor-provided and homegrown feature flag solutions natively. Instead of focusing on the feature level, most observability vendors treat each feature-flag toggle event (such as turning a feature on) like a new deployment or release. Teams then need to infer a feature’s impact by comparing metrics associated with requests before and after the toggle event.

Conversely, teams can integrate OpenFeature’s vendor-agnostic SDKs with any feature flag tool, easily enabling consistent observability support. By using our PurePath® technology for distributed tracing, Dynatrace can see all the feature flags that were evaluated for a given request and what values were returned. This allows teams to answer questions such as the following confidently.

• What impact did a feature flag value have on a request?
• Which services are using a particular feature flag?
• Did a combination of feature flags cause unexpected behavior?

Teams can also enable feature flags for a subset of users (for example, for beta testing or A/B testing). Observing these cases as you would a traditional deployment can result in the impact of a new feature becoming lost in the noise. By analyzing feature flags at the level of distributed traces, Dynatrace can collect statistically significant metrics and compare a new feature’s behavior to that of the control. This allows teams to make better, data-driven decisions.

What’s next for Dynatrace and OpenFeature?

OpenFeature provides the Dynatrace platform with a great opportunity to extend observability into feature flagging, allowing teams to monitor the deployment of a new feature, the results of an experiment, or a coordinated rollout. Combining this additional context with the already rich data within Dynatrace gives teams the confidence they need to safely release features without sacrificing velocity. With support for the Dynatrace Grail™ data lakehouse technology and Davis AI on the roadmap, now is the perfect time to start your journey with Dynatrace and OpenFeature.