[HN Gopher] OpenFeature: Standardizing Feature Flagging
___________________________________________________________________
OpenFeature: Standardizing Feature Flagging
Author : alexzeitler
Score : 37 points
Date : 2024-07-09 20:49 UTC (1 days ago)
(HTM) web link (openfeature.dev)
(TXT) w3m dump (openfeature.dev)
| janosdebugs wrote:
| After reading the specs, this sounds like an awful lot of
| complexity for something that should be simple and low cost. The
| spec also seems to be very loosely defined, more like a
| recommendation than a spec. This means you'll likely have to
| integrate a library and that library will be the authoritative
| source of truth as far as the expected behavior is concerned.
| scarlson wrote:
| That's the nature of having existing players with significant
| market share but no standardized spec. OTel was/is in the same
| boat where in order to be a successful project, first you have
| to integrate with the products orgs are already using.
| salil999 wrote:
| I'm confused as to why this needs to be standardized? OTel makes
| sense because multiple applications can consume metrics and logs.
| Feature flags are typically contained within a company and they
| typically don't need to be transferred across to other places.
| antonyt wrote:
| OTel made sense because there were multiple observability
| vendors eager to lock you in with proprietary formats and SDKs.
| The motivation behind OTel is to instrument once and ship
| anywhere, whether your vendor is Datadog, Splunk, Sentry, or
| whatever.
|
| This seems to be the same thing for feature flags, because
| these days people are farming FF management out to vendors like
| LaunchDarkly.
___________________________________________________________________
(page generated 2024-07-10 23:02 UTC)