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

It's OK to hardcode feature flags

code.mendhak.com

Post reply on HN
Print view View original

11–20 of 111 posts

Re: It's OK to hardcode feature flags

#11

Post by hirsin »

Kwpolska wrote: post #10
simonw wrote: post #5

The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…

> using an (often expensive) feature flags as a service platform I have no idea why anyone would actually do that in real life. Feature flags are something so trivial that you can implement them from scratch in a few hours, tops — and that includes some management UI.

You'll still be building management UI over their system (it doesn't understand or validate actor types, tenants, etc, so you have to do that.).

But at high throughput, you might want something with dedicated professional love. Ten thousand feature flags, being checked at around 2 (or 200) million RPS from multiple deployments... I don't want to be the team with that as their side project. And once you're talking a team of three to six engineers to build all this out, maybe it makes sense to just buy something for half a million a year. Assuming it can actually fit your model.

Re: It's OK to hardcode feature flags

#13

Post by elliot07 »

simonw wrote: post #5

The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…

I agree with a lot of this, except for the part about de-risking deployments. That should not be a reason why to adopt a feature flag platform - that is a symptom of a bad deployment pipeline that should be fixed which is a whole other story.

Re: It's OK to hardcode feature flags

#14

Post by rav »

echelon wrote: post #9
simonw wrote: post #5

The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…

> build-vs-buy Roll your own. Seriously. Feature flags are such an easy thing that there should be a robust and completely open source offering not tied to B2B SaaS. Until then, do it in house. My team built a five nines feature flag system that handled 200k QPS from thousands of services, active-active, local client caching, a robust predicate DSL for matching various conditions, percent rollout, control plane, ACLs…

I don't understand what a dedicated "completely open source offering" provides or what your "five nines feature flag system" provides. If you're running on a simple system architecture, then you can sync some text files around, and if you have a more scalable distributed architecture, then you're probably already handling some kind of slowly-changing, centrally-managed system state at runtime (e.g. authentication/authorization, or in-app news updates, ...) where you can easily add another slowly-changing, centrally-managed bit of data to be synchronised. How do you measure the nines on a feature flag system, if you're not just listing the nines on your system as a whole?

Re: It's OK to hardcode feature flags

#15

Post by frank00001 »

The whole point is to reduce the risk of the deployments by easily managing the flags - often without the need for a developer. Also, using services like Azure App Configuration gives you the possibility to have different distribution based on users, groups, country etc, which is a really useful.

A bit surprised people rolls their own implementation when this is easily available, and not that expensive. At least in Azure.

Re: It's OK to hardcode feature flags

#16

Post by joshmanders »

tdumitrescu wrote: post #8
simonw wrote: post #5

The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…

Seriously. This is one of those cases where rolling your own really does make sense. Flags in a DB table, flags in a json file, all super simple to build and maintain, and 100x faster and more reliable than making the critical paths of your application's request cycle depend on an external provider.

You know what I would find worse than telling my customers that they can't access the application they paid for and works because I farmed my auth out to a 3rd party that is having an outage?

Telling them that my auth provider isn't out, but the thing I use to show them a blue button vs a red button is.

Oof.

Re: It's OK to hardcode feature flags

#17

Post by duke_sam »

elliot07 wrote: post #13
simonw wrote: post #5

The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…

I agree with a lot of this, except for the part about de-risking deployments. That should not be a reason why to adopt a feature flag platform - that is a symptom of a bad deployment pipeline that should be fixed which is a whole other story.

The risk of deployments isn’t entirely technical. Depending on your business and customer base it might be necessary for some groups to have access to the feature earlier or later than others.

Re: It's OK to hardcode feature flags

#19

Post by fiddlerwoaroof »

forinti wrote: post #6

I've had an issue with gitlab feature flags when gitlab became unavailable. I couldn't fire a new deploy and the system wouldn't work until gitlab came back to life. That was a stupid dependency.

This sounds like an integration issue: systems like LaunchDarkly typically allow you to specify a default value for when the feature flag server can’t be reached.

Re: It's OK to hardcode feature flags

#20

Post by [deleted] »

joshmanders wrote: post #16
tdumitrescu wrote: post #8

Earlier quoted context omitted.

Seriously. This is one of those cases where rolling your own really does make sense. Flags in a DB table, flags in a json file, all super simple to build and maintain, and 100x faster and more reliable than making the critical paths of your application's request cycle depend on an external provider.

You know what I would find worse than telling my customers that they can't access the application they paid for and works because I farmed my auth out to a 3rd party that is having an outage? Telling them that my auth provider isn't out, but the thing I use to show them a blue button vs a red button is. Oof.

[deleted]
Post reply on HN