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

41–50 of 115 posts

Re: Principles for building and scaling feature flag systems

#41

Post by rubicon33 »

hn_throwaway_99 wrote: post #37
rubicon33 wrote: post #36

As an engineer, I am generally against feature flags. They fracture your code base, are sometimes never removed, and add complexity and logic that at best is a boolean check and at worse is something more involved. I'd love a world where engineers are given time to complete their feature in its entirety, and the feature is released when it is ready. Sadly, we do not live in that world and hence: feature flags.

This misses the point. A big point of feature flags is that you don't yet know how features will be perceived until you get them in front of real users. I get what you'd like "as an engineer", but it ignores the needs of the business.

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.

Re: Principles for building and scaling feature flag systems

#42

Post by imiric »

staplung wrote: post #15

This feels a bit like the dicta on 12 Factor: rules handed down from a presumed authority without any discussion of the tradeoffs. Engineering is tradeoff evaluation. Give me some discussion about the alternatives, when and why they're inferior and don't pretend like the proposed solution doesn't have shortcomings or pitfalls.

I agree with you that tradeoff evaluation is crucial in engineering, but I don't see the 12 Factor methodology as a set of strict rules. They're more like guidelines that are generally a good idea to follow for building modern applications or services. Some of the suggestions apply for any type of software, like having a single version controlled codebase, separate build/release/run stages, and using stateless processes.

So it's good to be aware of _why_ those guidelines are considered a good thing, but as with any methodology, an engineer should be pragmatic in deciding when to follow it strictly, and when to adapt or ignore some of it.

That said, I wouldn't want to work on software that completely ignores 12 Factor.

Re: Principles for building and scaling feature flag systems

#43

Post by vijayer »

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…

Could you add Statsig to your research?

Re: Principles for building and scaling feature flag systems

#44

Post by gingerrr »

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.

Re: Principles for building and scaling feature flag systems

#45

Post by adasdasdas »

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)

Re: Principles for building and scaling feature flag systems

#46

Post by bertil »

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…

I am tempted to agree: if separating the two is key (I’m not convinced that it is, but happy to assume) why not copy the interface and the infrastructure of the feature flag and offer it as a configuration tool.

I feel like you could easily add a status to flags, to mark whether they are part of a release process, or a permanent configuration tool, and in the latter case, take them off the release interfaces.

Re: Principles for building and scaling feature flag systems

#47

Post by dastbe »

mabbo wrote: post #38
baq wrote: post #31

Earlier quoted context omitted.

Or... see them for what they are: runtime configuration. The name implies a use case scenario, but in reality it's just a configuration knob. With a good UI, it's a pretty damn convenient way to do runtime configuration. So of course they'll be used for long-term configuration purposes, especially under pressure and for gradual rollouts of whole systems, not just A/B testing features.

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.

Could you expand on what you think the different interfaces should be? you keep stating that these things ought to be distinct but haven't explained why beyond dogma.

Re: Principles for building and scaling feature flag systems

#48

Post by PH95VuimJjqBqy »

hn_throwaway_99 wrote: post #37
rubicon33 wrote: post #36

As an engineer, I am generally against feature flags. They fracture your code base, are sometimes never removed, and add complexity and logic that at best is a boolean check and at worse is something more involved. I'd love a world where engineers are given time to complete their feature in its entirety, and the feature is released when it is ready. Sadly, we do not live in that world and hence: feature flags.

This misses the point. A big point of feature flags is that you don't yet know how features will be perceived until you get them in front of real users. I get what you'd like "as an engineer", but it ignores the needs of the business.

That is not what feature flags are typically used for.

They're typically used as a way of enabling a change for a subset of your services to allow for monitoring of the update and easier "rollback" if it becomes necessary.

They can be used for A/B testing, but this is not what they're typically used for.

Re: Principles for building and scaling feature flag systems

#49

Post by aranchelk »

gastonfournier wrote: post #30
aranchelk wrote: post #14

With regard to web-based services, once you’ve got the ability to do canary testing, IMO flags/toggles are less compelling — busier code and logic you’ll have to pull out later.

I agree that if you have only a few changes going to prod, fast and doing canary testing, you should be covered. In my experience that's rarely the case because of multiple teams deploying changes at the same time, and even deployments in external services causing side effects in other services.

Emergent inter-service issues are challenging to deal with regardless.

I’ve absolutely seen canary testing work in large environments with a lot of teams doing frequent deploys. The teams need to have the tooling to conduct their own canary testing and monitoring.

As soon as you’re involving external services or anything persistent you may not be able to undo the damage of misbehaving software by simply disabling the offending code with a flag.

In practice the cost/benefit of feature flags has never proven out for me, better to just speed up your deploys/rollbacks, the caveat is I’ve only ever worked in web environments, I can imagine with software running on an end user device it could solve some difficult problems provided you have a way to toggle the flag.

Re: Principles for building and scaling feature flag systems

#50

Post by hamandcheese »

zellyn wrote: post #25
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…

Sadly, this is a battle you are destined to lose. I have almost completely given up. The best you can aim for is to use feature flags better rather than worse. - Some flags are going to stay forever: kill switches, load shedding, etc. (vendors are starting to incorporate this in the UI) - Unless you have a very-easy-to-use way to add arbitrary boolean feature toggles to individual user accounts (which can become its…

Thank you for this great list of the immense business value derived from "misusing" feature flags!
Post reply on HN