search

open-telemetry / opentelemetry-demo

This repository contains the OpenTelemetry Astronomy Shop, a microservice-based distributed system intended to illustrate the implementation of OpenTelemetry in a near real-world environment.
https://opentelemetry.io/docs/demo/
Apache License 2.0
1.67k stars 1.03k forks source link

Create a feature flag service #40

Closed austinlparker closed 2 years ago

austinlparker commented 2 years ago

Objective

To allow for dynamic modification of service behavior through feature flags, and to demonstrate OpenTelemetry in another language, create a feature flag service in Erlang+Elixir/Phoenix.

Other services in the application should be able to register with this service and query it for the state of any feature flags defined in their code.

If feasible, it would be good to see if we can align with OpenFeature for definitions/semantic conventions here.

tsloughter commented 2 years ago

OpenFeature looks pretty early and focusing on hooks and evaluation at this point. I'd be fine modeling the feature flag data model off of them but I don't see a clear spec for that. I don't think we should, at least at this point, do any more than the most basic of, "is this flag true or false".

Happy to base the data structure on openfeature so it could in the future, if deemed useful, do more advanced forms of feature evaluation, if it is there in the spec and I'm just missing it :).

beeme1mr commented 2 years ago

Hey @austinlparker and @tsloughter, I'm working on OpenFeature and would love to help out where we can. Our project is still in an early stage but I think it would make sense to align where possible.

I would recommend you continue building out everything you described above but consider using the OpenFeature SDK and a custom provider that interacts with your service. That would fit nicely into our provider pattern we've defined in the spec. Ping me if you have any questions.

austinlparker commented 2 years ago

Is there an OpenFeature SDK for Erlang?

austinlparker commented 2 years ago

... and, I guess, every other language that would need to evaluate flags. 🙃

austinlparker commented 2 years ago

OpenFeature looks pretty early and focusing on hooks and evaluation at this point. I'd be fine modeling the feature flag data model off of them but I don't see a clear spec for that. I don't think we should, at least at this point, do any more than the most basic of, "is this flag true or false".

Yeah, this is mostly what I was thinking at this point. Targeting and other more advanced stuff seems pretty out-of-scope (or, at least, is something that can be handled manually). I was mostly hoping to align to OF semconv attributes for reporting flag state. That said, if there are relatively usable SDKs in that we can piggyback off for reading flag state from the ff service then that'd be nice.

beeme1mr commented 2 years ago

Is there an OpenFeature SDK for Erlang?

No, not yet. In fact, we don't have any SDKs ready for use but Java and Node is nearing an alpha state.

beeme1mr commented 2 years ago

Using the semantic conventions would be a great start. If timing is an issue, you should probably build your own simple solution and we can circle back later. I would be interested in adding more advance feature flagging use cases to this demo app because it would be a great way to show the value of feature flagging on a distributed trace.

tsloughter commented 2 years ago

great way to show the value of feature flagging on a distributed trace.

That would be neat.

I'll keep going ahead with what we have now. I'll try to check on OpenFeature from time to time, but would be great if you could let us know here when there is more development that we could start incorporating.