FOLIO Feature Flags

Context

Problem Statement

FOLIO is a microservice system with dozens to hundreds of microservices, and each module manages feature flags in its own specific manner. Currently, some modules use Spring Boot profiles, most use environment variables, and others use module-specific configurations or internal data storages for feature flags. It is challenging to manage everything, especially for DevOps, who need to set up numerous environment variables for multiple services. Moreover, these environment variables can have dependent variables and other conditions that are module-specific.

Use Cases

• Kill-switch: a new feature that has a blocker bug and must be disabled for all environments and tenants by FSE

• Tenant-specific feature: one of the tenants prefers to enable/disable specific feature with or without FSE help

• Consuming Versioned API: using specific API version depending on the feature flag value

Non Functional Requirements

• Maintainability: has good documentation and is easy to set and configure

• Configurability: supports flexible configurations and centralized point of configuration

• Compatibility: has Java and javascript clients

• Testability: should allow testing all permutations of a feature flag in the integration environment

Solution Options

The available open source options are listed in the table below.

Combining one of the solution options with Openfeature Specification would allow FOLIO to achieve centralized feature flag management within multitenant environments and for self-hosted deployment.

Target Solution

Assumptions

1. Flags are short-lived (a single release in general)

2. No gradual releases are required for FOLIO atm

3. The main type of flags is the so-called "kill-switch" flags

Constraints

1. As FOLIO is an open-source project, the solution should be based on an open-source technology stack.

Implementation Guide

Most of the out-of-the-box open-source products for feature flag management have their limitations for non-enterprise or self-hosted versions. Examples are:

• Unleash has limitations per supported environments (only development and production)

• flagd has no UI, which would impede the manual testing process

• etc.

Because of these limitations, it is recommended to do the following:

1. Base the solution on a backend library or module that would provide a related API for frontend modules

2. Implement the library as a provider for Open Feature specification. This will not only allow to unify the implementation across different FOLIO modules and teams but also will provide a possibility to substitute FOLIO feature flag provider with any OpenFeature compliant provider, including opensource products e.g. Unleash or enterprise SaaS solutions like LaunchDarkly.

Solution Details

OpenFeature provides a shared, standardized feature flagging client - an SDK - which can be plugged into various 3rd-party feature flagging providers. Whether you're using an open-source system or a commercial product, whether it's self-hosted or cloud-hosted, OpenFeature provides a consistent, unified API for developers to use feature flagging in their applications. (Introduction | OpenFeature )

Key aspects of the implementation:

1. Use OpenFeature specification

2. Each module should manage its own flags in the module's database, both for the backend and the frontend

3. Avoid dependencies on feature flags of other modules

4. Implement "provider" for feature flags:

   1. For Spring-Way modules, it can be implemented as a "spring boot starter" with the following functionality:

      1. Creates the flags table in the tenants database. Fields: key, expiration, enabled, variants: json, context: json

      2. On module enabling: should get flags from a configuration file and add them to the table

      3. Implement the evaluation logic described in OpenFeature specification

Testing Approach

1. The solution should allow for testing for all flag permutations for unit and e2e testing.

2. The flag values should be available for change from either the UI or the DB

3. There should be no dependencies for a flag from other flag values. In case it is required use flag variants