Dynatrace, together with an industry consortium including top feature flagging management solutions, has submitted a new open standard for feature flagging as a CNCF sandbox project. Feature flags are an essential tool in the modern software delivery lifecycle for cloud-native applications. This new standard will provide a vendor-neutral and future-proof approach for integrating feature flagging and management solutions to simplify, accelerate, and ultimately automate release cycles at scale.
Feature flagging and feature management are critical components in the effective delivery of cloud-native applications. They enable product delivery and SRE teams to turn functionality on and off at runtime without deploying new code. This helps SRE teams quickly mitigate issues by turning off poorly-performing features, enabling features for specific subsets of end-users, or performing side-by-side A/B feature testing. This decoupling of code deployment from feature release is a crucial enabler for modern Continuous Delivery practices. Feature flags and feature management eliminate the need to maintain multiple long-lived feature branches within your source code and they simplify and accelerate release cycles.
Proprietary SDKs create adoption challenges
Feature flag solutions currently use proprietary SDKs with frameworks, definitions, and data/event types that are unique to their platforms. Because each solution is unique, teams are challenged in looking to leverage these platforms and integrate them with other tools. Common issues include:
Introducing OpenFeature, enabling easy and confident adoption for many use cases
OpenFeature is a language-agnostic and vendor-neutral standard for feature flagging. Standardizing feature flag management allows organizations to confidently and quickly get started using feature flags, know that a vendor-neutral SDK will help them avoid vendor lock-in, and enable them to increase release velocity and quality.
Dynatrace announced today that, along with a consortium of other technology leaders, including GitLab, LaunchDarkly, Split, and many more, it has submitted OpenFeature to the Cloud Native Computing Foundation (CNCF) for consideration as a Sandbox project.
OpenFeature simplifies feature flag use-cases from the most basic to the most advanced:
- For example, a new “skunkworks” project might leverage OpenFeature immediately, performing essential flag evaluation based on static environment variables.
- As the project matures, more robust sources for flag configuration could be used, perhaps a simple REST API, database, or structured configuration file.
- As the application usage increases in production, a vendor solution becomes more attractive. OpenFeature allows the migration from one feature flag “source-of-truth” to another without any changes in application code.
This is just one example; applications of any size or maturity can use OpenFeature.
OpenFeature and Dynatrace will drive automation of feature flagging and management at scale
As one of the initiative’s key drivers, Dynatrace will provide first-class, native support for feature awareness by leveraging the new standard. This will unlock the power of the Dynatrace platform for SRE teams to leverage feature flagging and feature management solutions and ultimately drive intelligent automation.
OpenFeature architecture enables flexibility
OpenFeature, as a specification for feature flagging, seeks to define unified semantics for feature flagging that can be mapped to most feature flag implementations, from in-house projects to the largest SaaS vendor. The specification focuses primarily on feature flag evaluation in application code, leaving the definition and management of feature flags up to the feature flag management system. The specification defines standard interfaces, functions, and behavior to enforce consistent usage patterns across languages and feature flag implementations.
Inspired by OpenTelemetry, OpenFeature will provide specification-compliant SDKs in various languages such as Java, Node, Golang, .NET, and more. SDKs are lightweight, developer friendly, and flexible. They comprise abstractions including providers, evaluation context, and hooks, which will be introduced in the future.
A provider is responsible for resolving flag values from a particular source of truth and is registered in the OpenFeature SDK. The provider can be powered by an existing feature flag management system such as CloudBees, Flagsmith, Harness, LaunchDarkly, Split, Unleash, and others. It’s also possible to build your own provider that can be backed by various sources, such as a Kubernetes ConfigMap, a Java properties file, or a custom-built REST API. This flexibility allows teams to choose the provider that best fits their needs.
The evaluation context is a well-defined structure that may contain system, user, and request-specific attributes. The evaluation context is passed to the provider before flag evaluation. Many providers support using this information to perform dynamic flag evaluation.
Hooks are a powerful concept that allows developers to tailor their use of OpenFeature. They provide a means of extending the out-of-the-box behavior by injecting functionality at various stages of the flag evaluation lifecycle. This can be useful for adding contextual data, logging, telemetry, validation, etc. OpenFeature aims to provide a handful of first-class hooks, for instance, a hook for OpenTelemetry integration.
What’s next?
OpenFeature is under development, and as part of the industry consortium, we’re planning a general availability release for Fall 2022. We’re actively drafting the spec, which is nearing alpha release, with spec-compliant SDKs to follow. Our application to become a CNCF project is currently under review, and we anticipate acceptance shortly.
Learn more and be part of defining a new open standard for feature flag management, created to support a robust feature flag ecosystem using cloud native technologies: https://openfeature.dev/.
Looking for answers?
Start a new discussion or ask for help in our Q&A forum.
Go to forum