Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principles for building and scaling feature flag systems

docs.getunleash.io

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Principles for building and scaling feature flag systems

#91

Post by patrick451 »

dasil003 wrote: post #72
rubicon33 wrote: post #35

Earlier quoted context omitted.

This hits the nail on the head. The term "feature flag" has come to inherently have a time component because features are supposed to eventually be fulled GA'd. What I've seen in practice is feature flags are never removed so a better way to think about them is as a runtime configuration.

I think the reason feature flags are never removed is because the timeframe that a given feature-flag is top-of-mind is also when it's at its most useful. Later when it's calcified in place and the off-state may be broken/atrophied, no one is really thinking about it. I'm also not convinced it's always a huge problem. I can imagine sometimes it is, but in most codebases I've worked on, it's more of an annoyance but n…

The mental overhead of reading code like this is massive. Leaving feature flags in with the alternate branch left to rot leads to a codebase that is nearly impossible to understand. No purpose is served by not deleting the now unused branch except you save one developer an afternoon of work. But that time is quickly recouped when the entire team, and especially new hires, only have half as much code to understand.

Re: Principles for building and scaling feature flag systems

#92

Post by getrealyall »

mabbo wrote: post #12

> Make feature flags short-lived. Do not confuse flags with application configuration. This is my current battle. I introduced feature flags to the team as a means to separate deployment from launch of new features. For the sake of getting it working and used, I made the mis-step of backing the flags with config files with the intent to get Launch Darkly or Unleash working ASAP instead to replace them. Then another d…

The solution is not to use feature flags. Or maybe have them expire. Oh, also, discipline the developers who do this.

Re: Principles for building and scaling feature flag systems

#93

Post by getrealyall »

tvink wrote: post #85

>Organizations who adopt feature flags see improvements in all key operational metrics for DevOps: Lead time to changes, mean-time-to-recovery, deployment frequency, and change failure rate. Is this true? unfortunately there's no sources indicated, and a quick check on scholar doesn't show me anything of the sort.

This was written by a company selling feature flag software. Use that information as thou wilt.

Re: Principles for building and scaling feature flag systems

#94

Post by kiitos »

zellyn wrote: post #8
zellyn wrote: post #6

Background: I work at Block/Square, on the team that owns (but didn't build) our internal Feature Flag system, and also have a lot of experience with using LaunchDarkly. I like the idea of caching locally, although k8s makes that a bit more difficult since containers are typically ephemeral. People will use feature flags for things that they shouldn't, so eventually "falling back go default values" will cause product…

One more update. I spent a little time the other day trying to find all the feature flag products I could. I'm sure I missed a ton. Let me know in the comments! LaunchDarkly Split Apptimize CloudBees ConfigCat DevCycle FeatBit FeatureHub Flagsmith Flipper Flipt GrowthBook Harness Molasses OpenFeature Posthog Rollout Unleash Here's my first draft of the questions you'd want to ask about any given solution: Questionnai…

> Are flags evaluated in-memory, locally? (Hopefully!)

This seems like a MUST rather than a SHOULD, right?

Re: Principles for building and scaling feature flag systems

#95

Post by rubicon33 »

mrcarrot wrote: post #84
Rapzid wrote: post #81

Earlier quoted context omitted.

"Also, if one customer is having a particularly bad time we need to be able to disable the feature for them while continuing to collect feedback from everyone else."

“And management’s priority for Q4 is feature Y, so we’re just going to leave feature X like it is for now”

Exactly! And now feature X and the feature flag that governs it is in your code base forever.

In my opinion this all gets back to the way we build product and the expectations we have for our product managers. I have no doubt that their jobs are difficult in many ways, but the lack of actual focus on product specifically as it relates to customer sentiment always strikes me as lazy especially when that data collection is basically passed off to the engineers.

Re: Principles for building and scaling feature flag systems

#96

Post by gastonfournier »

tantalor wrote: post #89
Dirak wrote: post #64

Earlier quoted context omitted.

I feel like this is a solvable problem: 1) make feature flags be configured to have an expiration date. If over the expiration date, auto-generate a task to clean up your FF 2) If you want to be extra fancy, set up a codemod to automatically clean up the FF once it's expired I don't see the problem with developers using flags for configuration as a stopgap until there's a better solution available.

> automatically clean up the FF once it's expired Um what? How could that ever work. It's like you are trying to find new exciting ways to break prod.

It can be done by opening a PR, I haven't tried it yet, but I'm curious to try out https://github.com/uber/piranha or maybe hear some experiences if someone has used it

Re: Principles for building and scaling feature flag systems

#97

Post by [deleted] »

baq wrote: post #67
bluefirebrand wrote: post #61

Earlier quoted context omitted.

Allow me to try: Feature Flags inherently introduce at least one branch into your codebase. Every branch in your codebase creates a brand new state your code can run through. The number of branches introduced by Feature Flags likely does not scale linearly, because there is a good chance they will become nested, especially as more are added. Start with even an example of one feature flag nested inside another. That c…

Sorry, not buying it. Branches are difficult to reason about? Yes, I agree. Are branches necessary to make the product behave in a different way in some circumstances? Most of the time. Do those circumstances require a branch? Unless you’re super confident about some part of code, yes? But why would you be? Runtime configuration is not about making QA easy. It’s introduced because QA has been hell already so you can…

[deleted]

Re: Principles for building and scaling feature flag systems

#98

Post by tantalor »

gastonfournier wrote: post #96
tantalor wrote: post #89

Earlier quoted context omitted.

> automatically clean up the FF once it's expired Um what? How could that ever work. It's like you are trying to find new exciting ways to break prod.

It can be done by opening a PR, I haven't tried it yet, but I'm curious to try out https://github.com/uber/piranha or maybe hear some experiences if someone has used it

Which would be instantly rejected because the flag is still being used.

Re: Principles for building and scaling feature flag systems

#99

Post by sinuhe69 »

I know features flags like the flags of FF, but they are in fact config files. How does one realize dynamic control of features flags?

Are they using a kind of logic to determine to turn on/off a feature or do they query a central database to know that?

Can someone explain its basic mechanism? Thanks

Re: Principles for building and scaling feature flag systems

#100

Post by oddx »

I dedicated a day to evaluating feature flag software based on specific criteria:

    - Must support multiple SDKs, including Java and Ruby.
    - Should be self-hosted with PostgreSQL database support.
    - Needs to enable remote configuration for arbitrary values (not just feature flags). I don't run two separate services for this.
    - Should offer some UI functionality.
    - it should cache flag values locally and, ideally, provide live data updates (though pooling is acceptable).
Here are the four options that met these basic criteria and underwent detailed evaluation:

    - Unleash: Impressive and powerful, but its UI is more complex than needed, and it lacks remote configuration.
    - Flagsmith: Offers remote configuration but appears less polished with some features not working smoothly; Java SDK error reporting needs improvement.
    - Flipt: Simple and elegant, but lacks remote configuration and local caching for Java SDK.
    - FeatureHub: Offers fewer features than Unleash and Flagsmith; its Java API seems somewhat enterprisly but supports remote configuration and live data updates.
Currently, I'm leaning towards FeatureHub. If remote configuration isn't necessary, Unleash offers more features, and if simplicity is key and local caching isn't needed, Flipt is an attractive option.
Post reply on HN