Gold-plated booleans-as-a-service
yes, worth every penny
Cloudflare Flagship
121–130 of 189 posts
Re: Cloudflare Flagship
#122is it similar to vercel flags?
Re: Cloudflare Flagship
#123Earlier quoted context omitted.
Will never use them without prepayment or spending limit options. Insane to be a bug, attack, or misclick away from 6-7 digit invoice
the CTO of Cloudflare (hn: dknecht) said: > It is in the works. The billing team has been sprinting to fix a lot of debt in this area. I don’t have a date. https://x.com/dok2001/status/2051220429973389622
Great thanks
Re: Cloudflare Flagship
#124Earlier quoted context omitted.
When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies. A…
> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the fla…
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application.
If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code.
When I was at Shopify a couple of years ago they mandated that feature flags had to be short-lived (Like 2-4w lifetime tops, some had exceptions) because they would end up getting left in code and never cleaned up, or for extended periods of time like months. Hard to tell if it's genuinely a "feature flag" or actually just a normal part of the system at that point.
Feature flags being flipped in prod was also a major source of incidents, in part because people didn't treat them as experimental and with the associated risk profile of something experimental.
The only exception where having long-lived flags was useful and required was for operational killswitches (E.g. disable Apple Pay because it's having issues), but that is explicitly not application config.
Re: Cloudflare Flagship
#125Earlier quoted context omitted.
That sounds like the product is not finished and should not be released?
"If you are not ashamed by what you are shipping, you are not shipping early enough" (Quoting from memory)
That’s really about creating an MVP for a startup, because too many founders stay in a cave trying to make it “perfect” before collecting valuable user feedback.
This does not apply to Cloudflare, especially not for an auth token that needs to be published on your website that cannot be restricted.
Re: Cloudflare Flagship
#126Earlier quoted context omitted.
> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the fla…
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application. If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code. When I was at Shopify a couple of years ago they mandated that feature flags had to be shor…
I disagree with just about everything you said being a problem except the process of cleaning up is absolutely required.
Notably feature flags triggering incidents is expected and desired vs the alternative of shipping the code and having to roll a release back because there is no other way to remove the feature from prod.
Re: Cloudflare Flagship
#127Earlier quoted context omitted.
When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies. A…
> it just reminds me on how feature flags can be misused as application configuration/customization They literally are configuration.
Oh yeah lets make a web request per service invocation to figure out what to serve for the invocation!
Guys this is exactly the kind of banal crap that makes a simple app into a monsterous beast that won't work unless it's connected to the internet.
Re: Cloudflare Flagship
#128Earlier quoted context omitted.
When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies. A…
> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the fla…
One well known issue is that when you have a lot of separate feature flags that can interact, you explode the number of test cases you have to cover. For example if you have three feature flags that can interact in a module that has 100 test cases, you actually have 900 test cases if you are going to test with each possible combination of flags. Many teams don't test them all because they "already know" that doesn't apply here, and find out in production which combination of feature flags is unworkable.
Re: Cloudflare Flagship
#129Earlier quoted context omitted.
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application. If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code. When I was at Shopify a couple of years ago they mandated that feature flags had to be shor…
I disagree with just about everything you said being a problem except the process of cleaning up is absolutely required. Notably feature flags triggering incidents is expected and desired vs the alternative of shipping the code and having to roll a release back because there is no other way to remove the feature from prod.
In a company the size of Shopify people flipping their feature flags would very often impact *other teams*, and like I said feature flags got abused with even seemingly innocuous changes being put behind them or being left long periods of time before being fully used.
When someone else flips a flag that impacts your team and they have no idea they even caused a problem, it becomes very difficult to resolve the issue. Usually you can check for recent deploys, instead you have to go and guess at which feature flag which was recently flipped could possibly be affecting your code. I experienced this several times.
Also, it was actually more desirable for most of these things to go straight to production. Test it properly before shipping, then when you ship it soaks on a 5% traffic canary at which point you can monitor and cancel the deploy if you see errors. That is generally safer than a feature flag rollout unless you are doing something very high impact/risk, in large part because it gives any other team affected by your rollout the ability to respond and be able to easily find the source of errors.
In my org it was a fairly common failure mode to ship something and accidentally cause an issue for another team. Usually it was other teams/orgs shipping things that impacted us.
Re: Cloudflare Flagship
#130[flagged]