4 ms·

I don’t get it. Why is this needed above and beyond the standard ways of configuring deployed services?

ygouzerh 2y ago
Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).
- fire_lake 2y ago
  No I mean an entire framework and set of software components for doing feature flags.
  - GiorgioG 2y ago
    Clearly you haven't worked at an org that uses something like this extensively (LaunchDarkly for example.)
  - skeeter2020 2y ago
    If you have a single database than maybe you can (and should?) just start with a basic, single table approach, but as you grow in size and complexity FF management can become a challenge, with reporting gaps and feature release management. I usually see two charateristics with the former approach: growth in the # of FFs over time and a messy Excel report for what they are, do and if anyone still hits the old code. This might be fine for a while, or forever, but often gets painful.
- echoangle 2y ago
  But why do you need an external service for that? Isn’t that basically a single DB table with a name and an on/off value for each flag (or maybe an integer for multiple options)?
  - hobofan 2y ago
    In it's simplest incarnation, yes it could be just a single DB table with boolean flags. However there are a lot of connected needs that most real world-usages run into: - Per-user toggles of configuration values - Per-user dynamic evaluation based on a set of rules - Change history, to see what the flag value was at time of an incident - A/B testing of features and associated setting of tracking parameters - Should be controllable by e.g. a marketing/product manager and not only software engineers That can quickly grow into something where it's a lot easier to reach for an existing well thought out solutions rather than trying to home-grow it.
    - random_kris 2y ago
      In microservice world. Do you want to track features in each service or have a source of truth using flagd I prefer central source of truth
      - jacobr1 2y ago
        In a microservice world obviously you'd have a feature-flag service. But you still have a build/buy consideration.
    - j45 2y ago
      Great summary. The more parties involved with more and more configurations the more management of details is needed.

Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).

fire_lake 2y ago
No I mean an entire framework and set of software components for doing feature flags.
- GiorgioG 2y ago
  Clearly you haven't worked at an org that uses something like this extensively (LaunchDarkly for example.)
- skeeter2020 2y ago
  If you have a single database than maybe you can (and should?) just start with a basic, single table approach, but as you grow in size and complexity FF management can become a challenge, with reporting gaps and feature release management. I usually see two charateristics with the former approach: growth in the # of FFs over time and a messy Excel report for what they are, do and if anyone still hits the old code. This might be fine for a while, or forever, but often gets painful.
echoangle 2y ago
But why do you need an external service for that? Isn’t that basically a single DB table with a name and an on/off value for each flag (or maybe an integer for multiple options)?
- hobofan 2y ago
  In it's simplest incarnation, yes it could be just a single DB table with boolean flags. However there are a lot of connected needs that most real world-usages run into: - Per-user toggles of configuration values - Per-user dynamic evaluation based on a set of rules - Change history, to see what the flag value was at time of an incident - A/B testing of features and associated setting of tracking parameters - Should be controllable by e.g. a marketing/product manager and not only software engineers That can quickly grow into something where it's a lot easier to reach for an existing well thought out solutions rather than trying to home-grow it.
  - random_kris 2y ago
    In microservice world. Do you want to track features in each service or have a source of truth using flagd I prefer central source of truth
    - jacobr1 2y ago
      In a microservice world obviously you'd have a feature-flag service. But you still have a build/buy consideration.
  - j45 2y ago
    Great summary. The more parties involved with more and more configurations the more management of details is needed.