Hacker News Reader

Comment by ripperdoc | Hacker News Reader

Not directly related to Dorkly, but we've implemented feature flags (with our own system) and found them not super-useful and was hoping for more - but we may be doing it wrong. I can certainly see feature flags working well for us when activating e.g. new mostly UI-related features, but when many services and APIs need to change in unison for new features it seems a lot harder to use feature flags in practice. Then it goes beyond just putting new feature code behind conditions, as you might need to load different dependencies, offer different version of server APIs, run on different database schemas, etc. But maybe we are missing something?

View on HN

You need to organise your features in a way that these are not a problem. Need different dependencies - load both. Need a different schema - write both versions, drop old later. Need new services/APIs - feature flip only the user-visible one.

The flags are really useful for things like enabling just a fraction of traffic, or ensuring you can switch a feature off much quicker than a full deploy would take.

Everyone laughs when I say this but pull up a thesaurus. When you change the semantics of a thing, you have to change names to have old+new live at the same time. Don’t trust your mastery of English (especially if it’s your second language). There’s a synonym out there that describes the new behavior as well or even better.

Exhibit A.

For systems with many services that need 99.9..% uptime, the ways to do ANY change is things like expand-contract.

In most such cases you have several instances of your backend running in parallel for scaling and redundancy and when making a release, instances of several versions run concurrently. So you don't have a "atomic upgrade" available

With multiple services coordinating upgrade is even harder.

Patterns like expand-contract helps you manage this..E.g. first add the new endpoint to server, then move clients over, then remove old endpoint.

So..feature flags is just a way of dragging this process over longer time period, and roll over % of traffic. Instead of coupling changes to service releases you roll over using config.

Used them a lot in backend to backend, backend to DB etc scenarios, has been hugely useful to us and would never work without it.

But, of course depend on context what you are doing.

I'm also unrelated to Dorkly but I'm a big believer in feature flagging. It's key to moving fast as an engineering/product team.

be happy to walk you through how we use it. Shoot me an email if you want to chat. wayne at inaccord.com

Last time I did this, we ended up routing our flags through a reloadable config system which used Consul for distribution.

We almost never shared flags across our fairly chunky servicees. We usually found a softer way to do it.

Even with Consul, you can still have enough skew that a few requests in the middle might see A and !A if your request rate is high enough. So it depends on your business model and architecture if that’s acceptable.

You aren’t. This doesn’t mean that feature flags are useless or not worth it, but there’s no silver bullet. It is exactly as hard an engineering problem as it sounds.

Reply on news.ycombinator.com