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

71–80 of 111 posts

Re: It's OK to hardcode feature flags

#71

Post by PaulHoule »

dasil003 wrote: post #52
PaulHoule wrote: post #39

Earlier quoted context omitted.

In years of trying to sell things I've found that one of the best selling points to management is "susceptible to vendor lock-in", "you don't own your customer database", etc. I have no idea why that is.

I'm confused. Are you saying this ironically or have you literally pitched management with the risks of using your product?

I developed an open source "user management system" circa 2001 which I used on several sites, including one that had 400,000+ users, a famous preprint archive and the web site of a county-level green party. It was patterned on what sites like Yahoo and Amazon had at the time, did email verification and numerous things that were a hassle to implement, had great screens for the administrators, all of that.

I couldn't get anybody else to adopt this software despite putting a lot of work into making it easy to pick up and install.

10 years later competitors popped up like mushrooms and were adopted quickly. The thing they all had in common was somebody else owned your user database. So yeah I feel pretty cynical.

Re: It's OK to hardcode feature flags

#72

Post by ljm »

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 think openfeature.dev is an attractive proposition these days - start off with an env-based provider or roll your own and if you get to a point where you need to buy, you only need to swap over a provider (or use a multi-provider).

Re: It's OK to hardcode feature flags

#73

Post by withinboredom »

maccard wrote: post #63
superb_dev wrote: post #51

Earlier quoted context omitted.

We keep a JSON blob in Google Secret Manager for our flags. The service running in the container will reload the secret anytime it changes

Ah that’s a super nice feature. I’m mostly familiar with AWS who don’t have a neat way of doing this, you end up with a bespoke solution either with lambdas pushing to shared volumes or just polling s3 for updates.

If you are using kubernetes, you can mount the secret/ConfigMap as a volume and it will be updated automatically when changes occur. Then your application merely watches the file for updates.

Re: It's OK to hardcode feature flags

#74

Post by withinboredom »

thraxil wrote: post #50
jitl wrote: post #28

Earlier quoted context omitted.

When your app starts to get bigger and more complex, the idea of needing to restart a process to pick up any new kind of data starts to seem silly. Have seen the pattern many times: Hard-code values in code -> configure via env -> configure slow things via env and fast things via redis -> configure almost everything via a config management system I do not want to reboot every instance in a fleet of 2000 nodes just to…

I would add two things: It's often important that flag changes be atomic. Having subsequent requests get different flag values because they got routed to different backend nodes while a change is rolling out could cause some nasty bugs. A big part of the value of feature flags is to help avoid those kind of problems with rolling out config changes; if your flags implementation suffers from the same problem, it's not…

Making changes atomic is literally impossible, it's easier to just assume they won't be than chasing down something computer science tells us is impossible. I assume you are saying "every node sees the same change at the same time" when you say "atomic."

As for unit testing flags, you better unit test them! Just mock out your feature flag provider/whatever and test your feature in isolation; like everything else.

Re: It's OK to hardcode feature flags

#75

Post by dlevine »

I have found feature flagged rollouts to be one of the biggest advances in fairly recent software development. Probably too much to say about it in a comment, but they massively de-risk launches in a number of important ways, both in being able to quickly turn a feature off if it has unintended consequences and being able to turn it on for a very specific set of users.

With that said, I think that LaunchDarkly and the like are a bit expensive and heavyweight for many orgs, and leaving too many feature flags lying around can become serious debt. It totally makes sense to start with something lighter weight, e.g. an env var or a quick homegrown feature in ActiveAdmin.

Re: It's OK to hardcode feature flags

#76

Post by selfmodruntime »

ljm wrote: post #72
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 think openfeature.dev is an attractive proposition these days - start off with an env-based provider or roll your own and if you get to a point where you need to buy, you only need to swap over a provider (or use a multi-provider).

I like openfeature. Initially I thought that it was overengineered and quote honestly, I never grew to a size where I had to use anything but an env-provider paired with out CI/CD pipeline. But it gave me security that A/B testing would be possible if needed, and, more importantly, we had a unified API for feature flags and they were all defined in one place.

Re: It's OK to hardcode feature flags

#77

Post by the_mitsuhiko »

maccard wrote: post #48
the_mitsuhiko wrote: post #47

Earlier quoted context omitted.

> I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change and using an (often expensive) feature flags as a service platform: roll your own simple system. The middle ground is a JSON file that is copied up and periodically refreshed. We (Sentry) moved from a managed software to just a YAML file with feature flags that is pushed to all containers…

How do you push the files to all of your containers? I’ve done this in the past with app specific endpoints but never found a solution I liked with containers.

We currently persist the feature flag config in a database where the containers pull it from. Not the optimal solution but that was a natural evolution from a system we already had in place.

Re: It's OK to hardcode feature flags

#78

Post by selfmodruntime »

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

> feature flags in a JSON file that you have to redeploy to change Our config files are stored in their own repo. Pushes to the master branch trigger a Jenkins job that copies the config files to a GCP bucket. On startup, each machine pulls this config from GCS and everything just works. It's not a 'redeployment' in the sense that we don't push new images on each config change.

We do the same thing but slightly differently. If a new docker image is built, we deploy that image. If the config changes, an ansible job moves that config to the target host and the service is restartet with that new config file. Configs are mounted inside containers. It all runs on GitLab CI/CD.

Re: It's OK to hardcode feature flags

#79

Post by mcdoh »

whoknowsidont wrote: post #66

There's a typo in the article: >Hardoced feature flags Think the author obviously meant "hardcoded" here. Anyways, recently, this has been really hard to sell teams on in my experience. At some point "feature flag" became equivalent to having an entire SaaS platform involved (even for systems where interacting with another SaaS platform makes little sense). I can't help but wonder if this problem is "caused" by the u…

There's a typo in the post:

> Anyways

I think you obviously meant "anyway".

Re: It's OK to hardcode feature flags

#80

Post by whoknowsidont »

mcdoh wrote: post #79
whoknowsidont wrote: post #66

There's a typo in the article: >Hardoced feature flags Think the author obviously meant "hardcoded" here. Anyways, recently, this has been really hard to sell teams on in my experience. At some point "feature flag" became equivalent to having an entire SaaS platform involved (even for systems where interacting with another SaaS platform makes little sense). I can't help but wonder if this problem is "caused" by the u…

There's a typo in the post: > Anyways I think you obviously meant "anyway".

"Anyways" is not a typo. It's a well used term in informal contexts.
Post reply on HN