liveBook · Manning

Feature flag

As explained in Platform Engineering on Kubernetes

A feature flag is a runtime-controlled configuration mechanism that enables or disables application functionality without changing or restarting the application.

A feature flag lets a team deploy code for a new feature while keeping that feature hidden until it is ready to expose. A running application evaluates the flag to decide which behavior to use; the flag can then be changed without restarting the application. This separates releasing software from deciding when customers see a feature. section 7.3.4 section 7.5

An environment variable such as FEATURE_DEBUG_ENABLED=true is a simple starting point, but it becomes awkward across services: containers must restart to reread changed ConfigMaps, and teams need conventions for flag types, defaults, and status. A shared flagging capability instead gives services a consistent way to consume flags while the platform team manages how they are stored and updated. section 7.3.4 section 7.2

In the Conference application, each service uses the OpenFeature SDK to evaluate flags, with flagd configured as the provider. Application code can retain its flag checks if the platform team changes providers. This gives product-facing teams a way to decide when deployed features become visible without making that decision part of the deployment itself. section 7.3.5 section 7.4

Listing 7.7 Feature flag definitions, including variants
"eventsEnabled": {
     "state": "ENABLED",
     "variants": {
       "all": {
         "agenda-service": true,
         "notifications-service": true,
         "c4p-service": true
       },
       "decisions-only": {
          "agenda-service": false,
          "notifications-service": false,
          "c4p-service": true
        },
        "none": {
          "agenda-service": false,
           "notifications-service": false,
           "c4p-service": false
         }
       },
       "defaultVariant": "all"

The eventsEnabled definition has an enabled state and three variants: all enables events for three services, decisions-only enables them only for c4p-service, and none disables them for all three. Its default variant is all. section 7.3.5

Evaluate the flag in a service

A Conference service calls the OpenFeature SDK’s ObjectValue with the key eventsEnabled, an EventsEnabled default object, and an evaluation context. The returned value lets service code choose behavior according to the configured variant; changing the flag changes running-application behavior without a component restart. section 7.3.5 section 7.5

How Platform Engineering on Kubernetes covers it

How deep it goes
Works through multi-service flag variants and an SDK evaluation call, while leaving storage and provider management to the platform capability.
Examples
Uses FEATURE_DEBUG_ENABLED, a Conference eventsEnabled flag with three variants, and an OpenFeature ObjectValue call.
What it assumes
Assumes familiarity with containers and service code, but introduces why environment-variable flags need a more capable shared mechanism.
What you can do after
Apply it via OpenFeature to evaluate a shared flag and change a running Conference application's behavior without restarting components.
How it connects
Connects feature flags to OpenFeature, flagd, Kubernetes ConfigMaps, environment variables, and platform APIs.

Also explained in

Compare how 8 books explain feature flag →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Platform Engineering on Kubernetes. The section links point to the parts of the book it draws on.