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

171–180 of 189 posts

Re: Cloudflare Flagship

#171

Post by 1vuio0pswjnm7 »

Cthulhu_ wrote: post #145
tybit wrote: post #108

Earlier quoted context omitted.

I’ve seen whole teams at companies set up fail to provide these booleans-as-a-service well. There are whole companies like LaunchDarkly for them. If you boil it down to this, you may as well boil down every service that exists to bits-as-a-service. Turns out theres legitimate business value in these things, and complexity in delivering them.

It's like saying Dropbox is just rsync.

IIRC Dropbox was originally created using librsync

Dropbox has modified it

https://github.com/dropbox/librsync

This is why I prefer open source software. I can modify it

One person can use librsync to create a Dropbox company. Another person can use librsync for noncommercial purposes, e.g., to transfer and sync their own files

Either way, it's librsync

Re: Cloudflare Flagship

#172

Post by cush »

tybit wrote: post #108
paulbjensen wrote: post #95

Gold-plated booleans-as-a-service

I’ve seen whole teams at companies set up fail to provide these booleans-as-a-service well. There are whole companies like LaunchDarkly for them. If you boil it down to this, you may as well boil down every service that exists to bits-as-a-service. Turns out theres legitimate business value in these things, and complexity in delivering them.

The data science is where the real value comes in. 10x flags changed this release - which one caused the improved CTR? Booleans as a service need to address this, and there are benefits to having your boolean service live next to your other services

Re: Cloudflare Flagship

#173

Post by tailscaler2026 »

chambers wrote: post #168
la_fayette wrote: post #111

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

Yes, feature flags are conflated with remote configs (or its more useful variety: "dynamic configs"). The difference is subtle, hence why people are talking past each other. Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1]. For example: # Feature flag — variant gate for rollout flag = sdk.check_gate(…

I think feature flags, remote configs, and experiments are all the same thing. Semantically they differ in how you're applying the config and interpreting the outcomes.

Re: Cloudflare Flagship

#174

Post by strongpigeon »

matheusmoreira wrote: post #161
misbau wrote: post #159

I am a mere mortal when it comes to understanding the technicalities, but I know i find it relatively easy to use Cloudflare and all I want to say is keep up the good work.

Indeed. Best DNS registrar I've ever used.

I really liked Google Domains, but alas…

Re: Cloudflare Flagship

#176

Post by akoboldfrying »

jeremyjh wrote: post #128
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…

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…

But you have this same issue if you store those 3 bits of state as "app config" instead of as "feature flags".

I think it's useful to distinguish between kinds of feature flags -- "traditional" feature flags for safe rollout of new features (these should be removed on a strict timeline, to preserve maintainability) vs. "config"-type flags that are designed to remain indefinitely and optionally be configurable by certain end users. But I don't yet see a reason why the actual mechanism for these two things (namely, a function with a descriptive name that can be called to quickly return a small datum that is periodically refreshed from somewhere in the background) can't be the same.

Re: Cloudflare Flagship

#177

Post by tedk-42 »

epolanski wrote: post #150
tedk-42 wrote: post #127

Earlier quoted context omitted.

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.

There's no web request per service invocation. Feature flags are set once at startup (or specific events like hard refresh, or new login) and then simply included in the request headers. It's not rocket science, but I'm sure people are free to overcomplicate it.

That's not a feature flagging service then (config as a service! not a thing really...)

I've done both client and server side implementations of the launch darkly sdk and that's how it's done to know client context.

If you're initialising the entire SDK only to load 1 set of configuration items, I'd argue you can host the config as a json file on a CDN and be done with it - feature flagging is overkill.

Re: Cloudflare Flagship

#178

Post by jeremyjh »

akoboldfrying wrote: post #176
jeremyjh wrote: post #128

Earlier quoted context omitted.

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…

But you have this same issue if you store those 3 bits of state as "app config" instead of as "feature flags". I think it's useful to distinguish between kinds of feature flags -- "traditional" feature flags for safe rollout of new features (these should be removed on a strict timeline, to preserve maintainability) vs. "config"-type flags that are designed to remain indefinitely and optionally be configurable by cert…

Yes people are speaking past each other to some extent here; but if we're going to talk about "Feature Flags" we aren't talking about using a flag service for "normal" configuration - whatever that means. But what, exactly - does that mean? I normally consider things like the following configuration:

API Host Names, client Ids, secrets, Database connection strings Other runtime settings like pool sizes, replica counts etc

Most of those things are secrets, or they are specific scalar values closely tied to the application runtime, that often need to be known at startup. Are people putting those in a "feature flag" service? If not, what is a good example?

My comment only applies to "configuration" that alters behavior, usually in binary off/on manner. Which is what I'd call a "Feature Flag".

Re: Cloudflare Flagship

#179

Post by esafak »

hn_throwaway_99 wrote: post #91
bluelightning2k wrote: post #80

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

The flags (whether they be booleans, strings, numbers, or anything else) are the trivial part. It's the targeting and rollout rules (i.e. who gets to see which flags), and the requirements for extremely fast and consistent evaluation of these rules, that can get surprisingly complicated fast, and folks who have rolled their own usually find that product management or marketing or sales wants to target using more comp…

Feature flags and authorization abstract the same concept https://ntietz.com/blog/feature-flags-and-authorization/
Post reply on HN