3 ms·
One thing I see missing in this article is another huge cost to these things. What happens when your homegrown feature flag microservice (because why pay for a
by malfist 3y ago
One thing I see missing in this article is another huge cost to these things.
What happens when your homegrown feature flag microservice (because why pay for a hard cost when you can have the soft cost of making your own) goes down, even temporarily.
Sane defaults at code review time, before launch aren't always the sane defaults after a feature has fully launched, or nearly fully launched.
I've seen more than a few egregious outages due to a feature flagging tool being down and taking the user experience back a year or two.
- phyrex 3y agoAt my job feature flags (and other configuration) get distributed as static files that replaced by config updates, so if there’s ever a disruption the hosts still have the last valid code configuration values
- malfist 3y agoThat works for simple on off flags that can wait for a deploy to change. Adding rules on top of that become complex
- phyrex 3y agoNo, the deploy mechanism is separate from a code deploy. The rules themselves can get very complex and are distributed in the same way
- malfist 3y agoInteresting, I'd like to know more. Is it home grown? Or do you use something COTS?
- phyrex 3y agoIt's homegrown. This paper talks about it: https://research.facebook.com/file/877841159827226/holistic-configuration-management-at-facebook.pdf https://research.facebook.com/file/877841159827226/holistic-... It also mentions Gatekeeper, which is the rule-based engine I mentioned built on top of it, but there are other feature flag solutions that use configerator for different use cases like killswitches or gradual rollout.
- malfist 3y agoThank you for that!