2 ms·

I've been thinking about this topic for some time and love that someone else came to the same conclusion! There are a lot more differences in the requirements

by gneray 3y ago

I've been thinking about this topic for some time and love that someone else came to the same conclusion! There are a lot more differences in the requirements for these use cases though, e.g., feature flags products want for more analytics, controlled rollout, etc.; authorization, not so much. Authorization requires access to lots of shared application data/state; feature flags, not so much. Another area of overlap I see is entitlements/billing, e.g., can this person access this feature based on the plan they've signed up for? I've seen a lot of companies use the same underlying systems for feature flags, authorization, and entitlements (esp at earlier-stage companies and ones with a heavy DIY bent). Is this consistent with what others see/do?

jdwyah 3y ago
Consistency with what I’ve seen, but it can really end in tears. FF give you unbelievably useful and snappy ways to get what you want… at the cost of losing all track of what the state of the world is. Simple entitlement systems are clear and well modeled… at the cost of being too inflexible to get what you want :)
emptysea 3y ago
We use feature flags for entitlements and experiments at $work, it's all accessed through a consistent `hasFlag` API. Granted, our use is pretty straightforward, you either have access to product $Foo or you don't. I think with usage based billing, like first 100 messages free, or tier one gets 5MB uploads, tier 2 gets 50MB uploads it becomes harder to have a universal API, you end up having to do some manual checks. Still haven't really thought this all out but it's an interesting problem. Edit: also roles can provide entitlements / enable feature flags. So Admin could get every feature, while intern might get only get the analytics_read feature.
esafak 3y ago
There was a great article on this last year: https://arnon.dk/why-you-should-separate-your-billing-from-entitlement/ https://arnon.dk/why-you-should-separate-your-billing-from-e...

by gneray 3y ago

jdwyah 3y ago

Consistency with what I’ve seen, but it can really end in tears. FF give you unbelievably useful and snappy ways to get what you want… at the cost of losing all track of what the state of the world is. Simple entitlement systems are clear and well modeled… at the cost of being too inflexible to get what you want :)

emptysea 3y ago

We use feature flags for entitlements and experiments at $work, it's all accessed through a consistent `hasFlag` API. Granted, our use is pretty straightforward, you either have access to product $Foo or you don't. I think with usage based billing, like first 100 messages free, or tier one gets 5MB uploads, tier 2 gets 50MB uploads it becomes harder to have a universal API, you end up having to do some manual checks. Still haven't really thought this all out but it's an interesting problem. Edit: also roles can provide entitlements / enable feature flags. So Admin could get every feature, while intern might get only get the analytics_read feature.

esafak 3y ago

There was a great article on this last year: https://arnon.dk/why-you-should-separate-your-billing-from-entitlement/ https://arnon.dk/why-you-should-separate-your-billing-from-e...