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

81–90 of 115 posts

Re: Principles for building and scaling feature flag systems

#81

Post by Rapzid »

baq wrote: post #70
rubicon33 wrote: post #41

Earlier quoted context omitted.

Isn't that the job a product manager? There are other means and methodologies for gathering user sentiment before you go and build something. You should get as close as you can, release the product, and iterate. Todays world is release the product in some ramshackle form or fashion, collect feedback, iterate. To do that introduces a new construct of Feature Flags that would otherwise not be necessary.

Yeah product manager says ‘run this on 5% of traffic for 2 weeks and then we’ll see what the next iteration should be’.

"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."

Re: Principles for building and scaling feature flag systems

#82

Post by NBJack »

baq wrote: post #40
mabbo wrote: post #38

Earlier quoted context omitted.

There is a need for runtime configurations, yes, but it's important to put them behind an interface intended for that, and not one intended for something else.

I can immediately see if the config is being requested, which system requests it, what are the metadata of the request, etc. I can do conditional rollout of a configuration based on runtime data. I can reset the configuration to a know-good failsafe default without asking for approval with a break-glass button. I can schedule a rollout and get a reviewer for the config change. IME the feature flag interface is next t…

This gets messy at larger scales, both as teams grow and software grows.

Resetting to a know failsafe works as long ask the risk of someone changing a backend service (or, multiple services) at the same time is low. Once it isn't, you can most definitely do more damage (and make life harder for oncall).

Who controls the runtime config? One person? Half a dozen? One hundred plus? Is it being gated by approvals, or can anyone do it? What about auditability? If something does go wrong, how easily can I rule out you turning on that flag?

Finally there is simply the sheer permutations you introduce here. A feature flag is binary in many cases: on or off. A config could be in any number of states.

These things make me nervous as an architect, and I've seen well intentioned changes fail when good flag discipline wasn't followed. Using it as fullblown runtime config seems like a postmortem waiting to happen.

Re: Principles for building and scaling feature flag systems

#83

Post by stravant »

adasdasdas wrote: post #45

More principles - Require in code defaults for fault tolerance - Start annoying the flag author to delete if the flag is over a month old - Partial rollout should be by hash on user id - Contextual flag features should always be supplied by client (e.g. only show in LA, the location should be provided by client)

Better yet require always the same default for boolean flags, so that it's easier to reason about lifecycle for them.

Re: Principles for building and scaling feature flag systems

#84

Post by mrcarrot »

Rapzid wrote: post #81
baq wrote: post #70

Earlier quoted context omitted.

Yeah product manager says ‘run this on 5% of traffic for 2 weeks and then we’ll see what the next iteration should be’.

"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”

Re: Principles for building and scaling feature flag systems

#85

Post by tvink »

>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.

Re: Principles for building and scaling feature flag systems

#86

Post by triyambakam »

dabeeeenster wrote: post #55

For those that dont know about the project, check out Open Feature https://openfeature.dev/ which is sort of like Open Telemetry but for feature flags. Helps avoid vendor lock in. We're a young project and looking for help and to build the community!

Wow, part of the CNCF. That's awesome

Re: Principles for building and scaling feature flag systems

#87

Post by flitzofolov »

gingerrr wrote: post #44
jacomoRodriguez wrote: post #39

Is it just me or does this articles text structure and wording strongly indicate that is was written by gpt?

Definitely getting strong uncanny valley prose vibes. Hard to tell if it's generated or written in an attempt to be as plain English as possible, but either way feels strangely vacuous for a technical opinion piece. There's no writer's voice.

It's not really an opinion piece is it? It's docs. The language seems appropriate for articulating principles.

Re: Principles for building and scaling feature flag systems

#89

Post by tantalor »

Dirak wrote: post #64
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…

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.

Re: Principles for building and scaling feature flag systems

#90

Post by tpetr »

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…

Also https://prefab.cloud
Post reply on HN