Nicolai Ort
0e24bf4fd6
Some checks failed
Build latest image / build-container (push) Failing after 50s
31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
---
|
|
title: "Type-safe feature flagging in openfeature: Lessons learned from using feature flags at google"
|
|
weight: 2
|
|
tags:
|
|
- kubecon
|
|
- dev
|
|
---
|
|
|
|
{{% button href="https://youtu.be/mewXGSwDCE4" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}}
|
|
{{% button href="https://static.sched.com/hosted_files/kccnceu2025/f6/Type-safe%20Feature%20Flagging%20in%20OpenFeature.pdf" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}}
|
|
|
|
## Featureflags?
|
|
|
|
- Idea: Change the behaviour of an application without rebuilding it
|
|
- Goal: Control rollout, reduce risk, experiment (a/b)
|
|
- At google: A huge number of feature flags (150k+) but that's because people forget to turn them off
|
|
|
|
## Where does the flag come from
|
|
|
|
- Lifecycle of a flag: Create, Manage, Deprecate, Delete -> But will it be created frist in code or in the service
|
|
- Classic implementation: Just a if/else that uses a function to get the flag
|
|
- Problem: What if the flag names missmatch between the code and flag ser -> Muliple sources of truth
|
|
- Solution: Require use of auto-generated flag bindings (codegen from the management system) to mitigate typos, etc.
|
|
|
|
## OpenFeature
|
|
|
|
- Goal: Vendor agnostic, standardized, open source
|
|
- Basic setup: Register provider (once per app), create a client, use client to get flags
|
|
- CLI: Integrate into management system, keep a local manifest of all flags and generate code (generates the client)
|
|
- Now: Just call the client's method instead of hard-coding feature flag names
|