5 ms·

Just because they have the same implementation doesn't mean they're the same concept. The concept behind feature flags is, "this person will have access to thi

Just because they have the same implementation doesn't mean they're the same concept. The concept behind feature flags is, "this person will have access to this feature some day, and I (am / am not) ready for them to see it yet." They're shortlived, tend to be sprinkled throughout the codebase, and need to be aggressively removed to prevent a mess. The consequences for failure are usually minor. The concept behind authorization is, "this person (does / does not) have this capability, and they absolutely must not be given capabilities they don't have." They're long lived, have extraordinary consequences for failure, and need careful design to make sure they're centralized and easy to reason about. These are vastly different needs that demand different design approaches.

jacknews 4y ago
What if features are permanent, eg users in Brazil get to see certain products, a special import-tax panel, etc, but no-one else does? What if authorized users leave? The concepts are similar if not the same if you ask me (access control), just as the article points out, but they generally have different uses and patterns of use, again, just as the article points out.
- jdlshore 4y ago
  > users in Brazil get to see certain products, a special import-tax panel, etc, but no-one else does That's authorization. Feature flags were invented to enable continuous integration and trunk-based development. Ultimately, they're an alternative to feature branches. If you wouldn't create a git branch for it, you shouldn't create a feature flag for it.
  - brightball 4y ago
    Exactly. Additionally, you roll out feature flags incrementally and hand control of them to your product team to use to gather user feedback. Beta users, alpha users, individual users or companies. It’s on a case by case basis as feedback is gathered to refine the feature before it goes to general availability. Another option that is getting popular is to randomly grant access to a certain percentage of users over a series of days to track the rollout and watch for errors/user complaints. Often, you end up capturing statistics for usage on wrapped features as well. These are all very different than authorization.
  - 8note 4y ago
    This is not mutually exclusive is the thing. Commonly, you will put a feature behind a feature flag, and roll it out locale by locale, or never. You build a new feature that only works for a certain place, and you turn it on via a feature flag, and then you expand it to new places, also using a feature flag I guess the question is when do you grant authorization? Before or after the feature has launched in a region?
  - jacknews 4y ago
    This is just a different use of the same concept, as I and the article said. A feature flag grants or denies access to a feature in exactly the same way as authorization - you could have 'feature' attributes in an ABAC system for example, and in fact I'm sure many systems use exactly this to provide feature tiers. It's just that feature flags are generally used for a different purpose, ie targeted roll-out of new functionality, ie different policy concerns. So, different uses, different policies, but the same abstraction/concept.
  - creamyhorror 4y ago
    I recently wrote a small generalised feature to enable us to turn on flags for specific locales, specific user groups, or specific individual users, all specified in JSON strings stored in a DB (and which the backend caches). Some flags add a function or widget, while other flags add restrictions or change cronjob behaviour. Is this an authorisation or a feature flag system, or neither?
    - jdlshore 4y ago
      Sounds like it could be a component of the back end for either one. A complete feature flag system would also need a business-friendly front-end that product managers could use to roll out features and track how many people were using each one. Possibly an A/B testing component as well. And a way of alerting when a flag has been 100% active for X days so it could be removed from the code. Etc. A complete authorization system would need a front-end focused on understanding who had which capabilities, assigning capabilities to users and categories of users, and probably some sort of capability grouping and inheritance mechanism. Possibly an impersonation ability for the support team. Etc.
btown 4y ago
There's a lot of gray area, though. Consider the statement: "This person (does/does not) have the ability to see Widget X on their homepage." From the perspective of someone implementing the frontend or backend? It has all the characteristics of a feature flag. But what if Widget X shows something we are not allowed to sell to that person (say, per a specialized contract with their organization, or regional/legal limitations)? Then it's long lived, has extraordinary consequences for failure, and needs careful design to be able to model the person's membership in different (often overlapping) labels or organizations. We implement a `resolve_config` function used across our codebase, where different entities in our data model have a well-defined precedence order when they can override the value iff they match part of the hierarchical context. It's designed to be a near-zero-cost abstraction (cached locally so lookups can be done synchronously). That way, doing something that will roll out to some partners over time, and never to other partners, is as simple as using this function instead of a constant or literal. Edits at any level are audit-logged and can, when necessary, have approval procedures applied. It's an authorization system, at its core, but with arbitrarily typed values rather than boolean authorized-or-not flags. And I can't imagine building a B2B or B2B2C business without it.
1MachineElf 4y ago
You may very well want to keep both separate if your business requires separation between the people who control software feature flags vs. the people who determine access entitlements.

jacknews 4y ago

What if features are permanent, eg users in Brazil get to see certain products, a special import-tax panel, etc, but no-one else does? What if authorized users leave? The concepts are similar if not the same if you ask me (access control), just as the article points out, but they generally have different uses and patterns of use, again, just as the article points out.

jdlshore 4y ago
> users in Brazil get to see certain products, a special import-tax panel, etc, but no-one else does That's authorization. Feature flags were invented to enable continuous integration and trunk-based development. Ultimately, they're an alternative to feature branches. If you wouldn't create a git branch for it, you shouldn't create a feature flag for it.
- brightball 4y ago
  Exactly. Additionally, you roll out feature flags incrementally and hand control of them to your product team to use to gather user feedback. Beta users, alpha users, individual users or companies. It’s on a case by case basis as feedback is gathered to refine the feature before it goes to general availability. Another option that is getting popular is to randomly grant access to a certain percentage of users over a series of days to track the rollout and watch for errors/user complaints. Often, you end up capturing statistics for usage on wrapped features as well. These are all very different than authorization.
- 8note 4y ago
  This is not mutually exclusive is the thing. Commonly, you will put a feature behind a feature flag, and roll it out locale by locale, or never. You build a new feature that only works for a certain place, and you turn it on via a feature flag, and then you expand it to new places, also using a feature flag I guess the question is when do you grant authorization? Before or after the feature has launched in a region?
- jacknews 4y ago
  This is just a different use of the same concept, as I and the article said. A feature flag grants or denies access to a feature in exactly the same way as authorization - you could have 'feature' attributes in an ABAC system for example, and in fact I'm sure many systems use exactly this to provide feature tiers. It's just that feature flags are generally used for a different purpose, ie targeted roll-out of new functionality, ie different policy concerns. So, different uses, different policies, but the same abstraction/concept.
- creamyhorror 4y ago
  I recently wrote a small generalised feature to enable us to turn on flags for specific locales, specific user groups, or specific individual users, all specified in JSON strings stored in a DB (and which the backend caches). Some flags add a function or widget, while other flags add restrictions or change cronjob behaviour. Is this an authorisation or a feature flag system, or neither?
  - jdlshore 4y ago
    Sounds like it could be a component of the back end for either one. A complete feature flag system would also need a business-friendly front-end that product managers could use to roll out features and track how many people were using each one. Possibly an A/B testing component as well. And a way of alerting when a flag has been 100% active for X days so it could be removed from the code. Etc. A complete authorization system would need a front-end focused on understanding who had which capabilities, assigning capabilities to users and categories of users, and probably some sort of capability grouping and inheritance mechanism. Possibly an impersonation ability for the support team. Etc.

btown 4y ago

There's a lot of gray area, though. Consider the statement: "This person (does/does not) have the ability to see Widget X on their homepage." From the perspective of someone implementing the frontend or backend? It has all the characteristics of a feature flag. But what if Widget X shows something we are not allowed to sell to that person (say, per a specialized contract with their organization, or regional/legal limitations)? Then it's long lived, has extraordinary consequences for failure, and needs careful design to be able to model the person's membership in different (often overlapping) labels or organizations. We implement a `resolve_config` function used across our codebase, where different entities in our data model have a well-defined precedence order when they can override the value iff they match part of the hierarchical context. It's designed to be a near-zero-cost abstraction (cached locally so lookups can be done synchronously). That way, doing something that will roll out to some partners over time, and never to other partners, is as simple as using this function instead of a constant or literal. Edits at any level are audit-logged and can, when necessary, have approval procedures applied. It's an authorization system, at its core, but with arbitrarily typed values rather than boolean authorized-or-not flags. And I can't imagine building a B2B or B2B2C business without it.

1MachineElf 4y ago

You may very well want to keep both separate if your business requires separation between the people who control software feature flags vs. the people who determine access entitlements.