Breaking up is(n't) hard to do!

Separating releases from deployments with vendor-neutral feature flags

Todd Baert�OpenFeature Maintainer, Dynatrace

Standardizing Feature Flagging for Everyone

What is a feature flag?

The code and infra is ready, but the business is not… perhaps due to:

• Legal or compliance considerations
• Pending press releases or marketing materials
• Associated work from another team
• Many more…

How many of us have found ourselves in this position?

Easy!

We can do better.

It’s worth it to do better.

It’s time to start taking feature flags more seriously�(but don’t take my word for it)...

“Being able to alter runtime behavior without deploying means we can quickly mitigate issues, enable features for subsets of production users or perform A/B style feature tests.”

https://twitter.com/mipsytipsy/status/1341555348054818817

https://tech.ebayinc.com/engineering/openfeature-with-contributions-from-ebay-submitted-to-cncfs-sandbox-program/

Let’s consider our previous fictional feature:

What if:

What if:

• The feature is implemented across multiple services?
• How do we coordinate deployment?

Let’s consider our previous fictional feature:

What if:

• The feature is implemented across multiple services?
• How do we coordinate deployment?
• Another option is suddenly required, or frequently added?
• (cowsay -f tux? -s? -t?)

Let’s consider our previous fictional feature:

What if:

• The feature is implemented across multiple services?
• How do we coordinate deployment?
• Another option is suddenly required, or frequently added?
• (cowsay -f tux? -s? -t?)
• We want to enable the feature for only 1 customer?
• All paying customers?

Let’s consider our previous fictional feature:

What if:

• The feature is implemented across multiple services?
• How do we coordinate deployment?
• Another option is suddenly required, or frequently added?
• (cowsay -f tux? -s? -t?)
• We want to enable the feature for only 1 customer?
• All paying customers?
• We want to enable the feature pseudo-randomly to see how it impacts usage or performance?
• We want variant assignment to be “sticky”.

Let’s consider our previous fictional feature:

What if:

• The feature is implemented across multiple services?
• How do we coordinate deployment?
• Another option is suddenly required, or frequently added?
• (cowsay -f tux? -s? -t?)
• We want to enable the feature for only 1 customer?
• All paying customers?
• We want to enable the feature pseudo-randomly to see how it impacts usage or performance?
• We want variant assignment to be “sticky”.
• We want to progressively roll the feature out to everyone?

Let’s consider our previous fictional feature:

https://martinfowler.com/articles/richardsonMaturityModel.html

Introducing the feature-flag maturity model:

The ENV_VAR swamp

0

Dynamic configuration

1

Dynamic evaluation

2

Operationalized feature-flags

3

Level 0: The ENV_VAR swamp

• Primitive feature-flags

Level 0: The ENV_VAR swamp

• Primitive feature-flags
• Configuration cannot be changed without a deployment or recompilation

Level 0: The ENV_VAR swamp

• Primitive feature-flags
• Configuration cannot be changed without a deployment or recompilation
• No contextual awareness
• Ex: user geo, remote IP, items in cart, AWS VPC, application version, etc

Level 0: The ENV_VAR swamp

• Primitive feature-flags
• Configuration cannot be changed without a deployment or recompilation
• No contextual awareness
• Ex: user geo, remote IP, items in cart, AWS VPC, application version, etc
• Little/no meaningful telemetry data

​

Level 0: The ENV_VAR swamp

Level 0: The ENV_VAR swamp

Level 1: Dynamic Configuration

• Configuration can be changed without a deployment or recompilation of the workload
• Feature-flag configuration “source-of-truth” is independent of application

Level 1: Dynamic Configuration

• Configuration can be changed without a deployment or recompilation of the workload
• Feature-flag configuration “source-of-truth” is independent of application
• Primitive contextual awareness
• Contextual data included in evaluation logic
• Evaluation logic is still duplicated: if (user in ENABLED_GEOS) and not centrally managed

​

Level 1: Dynamic Configuration

Level 1: Dynamic Configuration

• Configuration can be changed without a deployment or recompilation of the workload
• Feature-flag configuration “source-of-truth” is independent of application
• Primitive contextual awareness
• Contextual data included in evaluation logic
• Evaluation logic is still duplicated: if (user in ENABLED_GEOS) and not centrally managed
• Not a basis for robust experimentation

Level 1: Dynamic Configuration

Level 2: Dynamic Evaluation

• Centralized evaluation logic
• Rules are defined outside application logic
• Experiments can be deployed independently of application logic

Level 2: Dynamic Evaluation

Level 2: Dynamic Evaluation

Level 2: Dynamic Evaluation

Level 2: Dynamic Evaluation

• Centralized evaluation logic
• Rules are defined outside application logic
• Experiments can be deployed independently of application logic
• Fully observable
• See traces/spans and metrics, including what variant was used, why.
• Relevant contextual data

Level 2: Dynamic Evaluation

Level 3: Operationalized feature-flags

• Same technical features as Level 2, but fully integrated throughout the business and operations:

Level 3: Operationalized feature-flags

• Same technical features as Level 2, but fully integrated throughout the business and operations:
• Flag telemetry data and flag management is made accessible to relevant business units: made an asset
• (not a free-for-all)

Level 3: Operationalized feature-flags

• Same technical features as Level 2, but fully integrated throughout the business and operations:
• Flag telemetry data and flag management is made accessible to relevant business units: made an asset
• (not a free-for-all)
• Feature flags are leveraged in ongoing experimentation:
• Hypothesis testing (does feature-X improve conversion rate?, does UI-element-Y reduce bounce-rate)

Level 3: Operationalized feature-flags

• Same technical features as Level 2, but fully integrated throughout the business and operations:
• Flag telemetry data and flag management is made accessible to relevant business units: made an asset
• (not a free-for-all)
• Feature flags are leveraged in ongoing experimentation:
• Hypothesis testing (does feature-X improve conversion rate?, does UI-element-Y reduce bounce-rate)
• Canary releases and percentage-based rollouts reduce risk

Level 3: Operationalized feature-flags

• Same technical features as Level 2, but fully integrated throughout the business and operations:
• Flag telemetry data and flag management is made accessible to relevant business units: made an asset
• (not a free-for-all)
• Feature flags are leveraged in ongoing experimentation:
• Hypothesis testing (does feature-X improve conversion rate?, does UI-element-Y reduce bounce-rate)
• Canary releases and percentage-based rollouts reduce risk
• Offer opt-in beta testing or previews (target all users at contoso.com)

Level 3: Operationalized feature-flags

Introducing the feature-flag maturity model:

The ENV_VAR swamp

0

Dynamic configuration

1

Dynamic evaluation

2

Operationalized feature-flags

3

What’s OpenFeature?

OpenFeature is an open standard that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool.

Speaks Your Language

SDK implementations

We have 5 production-ready (v1.0+) SDKs released, with more on the way.

Supports Your Favorite Tools

Developed with the industry

The OpenFeature standard was developed in collaboration with the top feature flag and remote management vendors and OSS projects.

Why Standardize?

Standardizing feature flags unifies tools and vendors behind a common interface, avoiding vendor lock-in at the code level. It provides a framework for building extensions and integrations that can be shared across the community.

Why Standardize?

Conventional semantics for telemetry

A consistent API for application authors

Easier language support for vendors

Common paradigms for ecosystem development

Easier migration between solutions

Simplified testing and local development

Lower risk adoption

OpenFeature crash course

• Evaluation API: vendor neutral flag evaluation API
• Standard interface
• No awareness of flag management system (backend), targeting rules, etc

​

OpenFeature crash course

Provider: “adaptor” for flag management system

• Interface defined in OpenFeature SDK
• Allows Evaluation API to work with whatever flag management system you use (vendor or home-grown)

​

​

OpenFeature crash course

Hook: a flexible integration point

• Interface defined in OpenFeature SDK
• Allows addition of custom behavior at well-defined points in the flag evaluation life-cycle

​

​

OpenFeature crash course

Demo Time!

A realtime, vendor-neutral feature management platform built on cloud-native components

• OpenFeature SDK (JavaScript) included in our application, so we can use the evaluation API to evaluate flags
• flagd available to our application at runtime
• flagd is an OpenFeature-native feature flag evaluation daemon which can use local files, http-resources, K8s custom-resources and more as flag definitions
• The flagd provider for Javascript
• argo/OTel

Demo Time!

Standardizing Feature Flagging for Everyone