3 ms·

Can anyone else comment on the SaaS companies like LaunchDarkly - where (afaik) the meta data for your feature flags are stored on some server external to your

Can anyone else comment on the SaaS companies like LaunchDarkly - where (afaik) the meta data for your feature flags are stored on some server external to your company and this "enables you to instantly turn on or off features". I work in a big bank so this would just be laughed at, but has anyone used this? Why is it attractive at all? Surely there needs to be some release process of some sort ? what if they go down ? what if you stop paying them? How can you do useful things like "launch to only the Japanese users" without handing launchdarkly a list of japanese users? It's one of the weirder SaaS areas - almost all the cost of Flags is in the writing of the code (and removing it later). Not the bit flip. And if, as someone implies uothread, it's useful to speed up releases well, you are solving the wrong problem in very much the wrong way ..

mmahemoff 5y ago
It's much more than a bit flip - that's just the input. The output side is where tooling like this becomes useful, i.e., getting analytics on each variant. That's what lets you run A-B tests to optimise conversion, ensure a new feature isn't going to cause stabilty problems, etc. And then there's the need for interfaces to allow changes on a live system, and giving certain abilities to non-technical users who want to change settings on a simple web dashboard. If an external service goes down, the system should be able to degrade gracefully. I haven't used an external service, but I'd hope the SDK allows for a simple fallback strategy for each flag, such as random assignment or fixing to a particular value. Data collection should still resume once the external service is back up.
underwater 5y ago
We've used ConfigCat (highly recommended). They publish a configuration file and the web client determines if the user is enabled or not. Yes, this means we are paying for a UI and an SDK (plus an audit log and some integration into Slack and analytics) but it's still better than spending time writing a system ourselves. You have to assume anything shipped is going to be public, and use sane defaults in code in case the service goes down. Once you move to that model, the idea of releasing code and features simultaneously seems reckless.

mmahemoff 5y ago

It's much more than a bit flip - that's just the input. The output side is where tooling like this becomes useful, i.e., getting analytics on each variant. That's what lets you run A-B tests to optimise conversion, ensure a new feature isn't going to cause stabilty problems, etc. And then there's the need for interfaces to allow changes on a live system, and giving certain abilities to non-technical users who want to change settings on a simple web dashboard. If an external service goes down, the system should be able to degrade gracefully. I haven't used an external service, but I'd hope the SDK allows for a simple fallback strategy for each flag, such as random assignment or fixing to a particular value. Data collection should still resume once the external service is back up.

underwater 5y ago

We've used ConfigCat (highly recommended). They publish a configuration file and the web client determines if the user is enabled or not. Yes, this means we are paying for a UI and an SDK (plus an audit log and some integration into Slack and analytics) but it's still better than spending time writing a system ourselves. You have to assume anything shipped is going to be public, and use sane defaults in code in case the service goes down. Once you move to that model, the idea of releasing code and features simultaneously seems reckless.