[FEATURE] Utilize OpenFeature providers in flagd

[tcarrio]

Description

The goal here being that flagd would be able to plugin Go providers as the backend, as opposed to the JSON configuration.

Namely, the goal here would be to use the operator model built around the reference OpenFeature implementation, but collectively configure the provider at the flagd level instead of individual codebases.

Reasoning

For adoption of OpenFeature, this massively shifts the overhead for implementing providers per language to primarily Go, where that provider could be utilized in the sidecar instance of services using flagd.

For instance, we use Python, NodeJS, and PHP backed by Split. We would need to implement a Split OpenFeature provider in every language in order to adopt OpenFeature, and in addition to that we would have the initial overhead of migration from the Split SDK to OpenFeature, with no architectural benefit to doing so.

In the case of deploying to Kubernetes with the Flagd operator, we can immediately benefit from pod-local access to Flagd and configure the operator at a namespace (or even container level) which provider it would use.

The operator pattern, or just deploying of Flagd as a service available to the K8s namespace, would immensely improve our overall flexibility through OpenFeature. For example, the provider for OpenFeature can be optimized for asynchronous communication (re: Split's PHP provider is entirely synchronous) with Flagd doing the heavy lifting of individual request handling.

General food for thought, as this would likely be a blocker for our org adopting OpenFeature as an enhancement to our current architecture.

[AloisReitbauer]

Could you create an OFEP for this?

[AlexsJones]

I read that but I don't understand :(

[toddbaert]

@AlexsJones I think @tcarrio is suggesting something we've talked about a few times (I've heard it brought up independently by a few people): using go providers as evaluators in flagd.

Basically, since the interfaces are very similar (see the ievaluator.go, it should be possible to use a go provider as an evaluator). This would then basically mean flagd is "powered" by whatever provider you've plugged in (ie: flagd powered by LaunchDarkly or flagd powered by Flagsmith) instead of a particular sync provider supplying rules to the json_evaluator.

[tcarrio]

Exactly this @toddbaert. Where this really comes into play, as an interested party of the operator, is that we can now introduce any OpenFeature provider as the evaluator but automatically utilize deployment strategies of flagd by the operator (pod sidecars, node-local, etc).

The gains exist for flagd as its own service of course, where we can now utilize Split or LaunchDarkly in production but optimize the configuration of flagd deployments instead.

[tcarrio]

Could you create an OFEP for this?

I could look into this as well @AloisReitbauer 🙏

[tcarrio]

@AloisReitbauer @toddbaert @AlexsJones: drafted an OFEP for this enhancement here.

[beeme1mr]

Closing as this is considered out of scope.