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

31–40 of 115 posts

Re: Principles for building and scaling feature flag systems

#31

Post by baq »

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…

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.

Re: Principles for building and scaling feature flag systems

#32

Post by gastonfournier »

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

After typing that, and realizing I have a lot more to say, I guess I should write a blog post on the subject

Yes, please!

Re: Principles for building and scaling feature flag systems

#33

Post by zellyn »

baq wrote: post #31
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…

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.

Yeah, and assuming they are done well, they probably have better analytics and insights attached to them than anything else except perhaps your experiments!

Re: Principles for building and scaling feature flag systems

#34

Post by gastonfournier »

accountantbob wrote: post #19
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…

We did the same. We were early adopters of unleash and wrangled it to also host long term application configuration and even rule based application config. The architecture of unleash made it so simple to do in unleash vs having to evaluate, configure, and deploy a separate app config solution.

Victim of your own success. As others were saying, when it works for short-lived its easy/no effort to use it for long-lived configurations.

Re: Principles for building and scaling feature flag systems

#35

Post by rubicon33 »

baq wrote: post #31
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…

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.

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.

Re: Principles for building and scaling feature flag systems

#36

Post by rubicon33 »

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.

Re: Principles for building and scaling feature flag systems

#37

Post by hn_throwaway_99 »

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.

Re: Principles for building and scaling feature flag systems

#38

Post by mabbo »

baq wrote: post #31
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…

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.

Re: Principles for building and scaling feature flag systems

#40

Post by baq »

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.

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 to perfect for runtime configuration. I don't care for intended usage at all. You could say feature flags have found a great product-market fit, just that a segment of the market is a bit unexpected but makes perfect sense if you think about it.

Post reply on HN