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

Cloudflare Flagship

developers.cloudflare.com

Post reply on HN
Print view View original

131–140 of 189 posts

Re: Cloudflare Flagship

#131

Post by echelon »

ZephyrBlu wrote: post #124
baq wrote: post #120

Earlier 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…

Runtime evaluated feature flags can always be used for control plane levers and emergency handbrakes.

You just have to label them as such and prevent other teams from fiddling with them.

This is not an antipattern, it's just semantic hand-wringing.

My team managed critical systems in the online flow of billions of dollars of daily payment volume. We also wrote the feature flag system that the rest of the company used. Not only were we completely fine with feature flags as long-lived control plane levers, we heavily used the system that way ourselves.

You just have to clearly distinguish between ephemeral rollout flags (and clean them up or expire them) and the permanent control plane levers.

It's the exact same functionality for both sets of tools. Just different practices around the two usages.

Re: Cloudflare Flagship

#132

Post by ZephyrBlu »

echelon wrote: post #131
ZephyrBlu wrote: post #124

Earlier 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…

Runtime evaluated feature flags can always be used for control plane levers and emergency handbrakes. You just have to label them as such and prevent other teams from fiddling with them. This is not an antipattern, it's just semantic hand-wringing. My team managed critical systems in the online flow of billions of dollars of daily payment volume. We also wrote the feature flag system that the rest of the company used…

I completely agree with your distinction and that is exactly what they mandated :)

I don't think that is what most people colloquially mean by "feature flags" though. Even most teams in Shopify abused "ephemeral" flags for long periods of time.

When they rolled out the mandate it was very annoying for my team because we had a lot of operational flags like you're describing that we needed to get exemptions for.

Re: Cloudflare Flagship

#133

Post by philipwhiuk »

roerohan wrote: post #52
OptionOfT wrote: post #23

Earlier quoted context omitted.

Let's think about it. This is probably something used internally at CloudFlare and someone thought I'd be interesting to make it public. There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.

https://blog.cloudflare.com/flagship Here's why we built it!

Ah, no-look coding.

How can we possibly trust the AI to disable the 'CODE_IS_SKYNET' flag.

Re: Cloudflare Flagship

#134

Post by nijave »

pavo-etc wrote: post #109
tom1337 wrote: post #106

Earlier quoted context omitted.

how would a single JSON allow staged rollouts with sticky sessions?

you pick a frequency you want, represent that as a fraction, and modulo on user id, and your 80% of the way there

Assuming you want a random distribution and don't want to take any other attributes into account.

We're a small company but new feature release for big features is typically targeted at low risk users/customers first. That usually means a few attributes are taken into account (age, customer value, customer sentiment, which features they use)

Re: Cloudflare Flagship

#136

Post by nijave »

5701652400 wrote: post #103
ramon156 wrote: post #102

Earlier quoted context omitted.

I don't mind it. I don't want to keep track of thousands of feature flags in my DB, have to create an admin dash, etc. You could call any SaaS tool "excel-as-a-service" and it would hold the same power as your comment.

or maybe just make single JSON and commit it to git? your http server + GitHub + JSON and text editor is your admin ui, audit, etc.

Git is typically fairly slow if you have to wait on a test suite and deployment pipeline. Usually at least 10 minutes but sometimes 30, 60, 90+ minutes. A lot of purprose-built feature flag platforms hot reload the config in seconds.

JSON in the repo also risks introducing customer data to git if you want to rollout based on specific customer attributes (sometimes, for us, it's a list of early opt-in customers we have meetings with to discuss/develop new features)

It's also less accessible for "business users" like product/project managers, sales, and marketing they want to coordinate feature rollout with other business initiatives (and don't want to bother engineers when they do)

Re: Cloudflare Flagship

#137

Post by nijave »

risyachka wrote: post #118
gowthamgts12 wrote: post #64

Earlier quoted context omitted.

Their quality of the products they ship have already became shitty for quite a while now.

they are quickly turning into a slop shop instead of polishing their existing products (and most of them do require a lot of work) they jump into any other niche someone thought was a good idea. My guess is that with ai being able to prototype things quickly they just started doing everything that is even a bit relevant. which won't end well

I think they were doing that before AI got big the last couple years.

Their core network stuff always seemed pretty robust but all the newer stuff was much more thrown together. Thinking specifically of Zero Trust/Argo Tunnels which has been around a few years (and I do like) but has some rough edges.

Re: Cloudflare Flagship

#138

Post by nijave »

pjmlp wrote: post #100
iainmerrick wrote: post #98

Earlier quoted context omitted.

They have containers, does that count? If you’re specifically thinking of native ephemeral workers with very fast startup, it seems like those would have to be sandboxed somehow, and WebAssembly seems like a decent solution. Is there really a significant native code gap between WebAssembly workers and native containers?

Containers seem to only be "Available on Workers Paid plan" , whereas Vercel supports it on the hobby account as well. Kind of relevant on those cheapskate projects that only start paying licenses after the SOW is signed, but already expect some kind of prototyping in place. WebAssembly is a solution looking for a problem outside the browser, with worse development experience. If I want bytecode based runtimes, I alr…

Haven't used Vercel but back in the Heroku/CloudFoundry days it was pretty easy to jam arbitrary binaries into the runtime containers and some of the build packs were flexible enough you could override most of the functionality.

Not sure if that's possible/how easy it is on Vercel

Re: Cloudflare Flagship

#139

Post by nijave »

7thpower wrote: post #21
tiffanyh wrote: post #19

This is nice, but I’m still waiting for this to be delivered (which ironically is probably using Flagship): https://blog.cloudflare.com/enterprise-grade-features-for-al... —- I don’t believe a single enterprise only feature has made its way to lower tier (paid) account yet. I’m most interested in: https://developers.cloudflare.com/speed/optimization/content...

Yes, this! I am dying for need of zerotrust enterprise features and am about to have to actually talk to one of the enterprise sales folks, which will chew up a bunch of time and add stress I’d rather avoid.

Fwiw I didn't think Cloudflare sales was too bad when we dealt with them a year ago--at least compared to some companies.

Re: Cloudflare Flagship

#140

Post by nijave »

ZeWaka wrote: post #84
bluelightning2k wrote: post #80

I've never understood feature flags. How are they fundamentally different to a Boolean in a database?

They're not always booleans - for example, we often see feature flags being used for A/B rollouts. Cloudflare themselves even uses them internally as such, by shipping new features/builds to their free customers first, and then progressively larger customers after a settling period. Feature flags can also be randomly turned on, for a sort of fuzz testing. Don't think of them just as 'new things' - it could be 'change…

Really any "constant". Failure thresholds, timeouts, API versions or endpoints, LLM model id
Post reply on HN