Show HN: Canarybase – Remove feature flag code from your apps
canarybase.com
canarybase.com
You mention routes does that mean it only works with /api/v2/xxx-style services?
Finally requiring an email for a demo is a hard-pass, especially with so few details.
The routes are anything doable in Envoy, I currently use HTTP headers, but can be URI as well, for instance:
You have a container running version 1.0.0 of you app. You deploy a second container with version 1.0.1. We create a rule in Envoy saying that any request with the HTTP header ‘X-version: 1.0.1’ should go to the second container. Anything else continues to work normally.
Envoy supports a lot of http attributes, also works with GRPC, and support for other TCP protocols are coming.
Also, there is Envoy mobile, which is going to enable these rules to be create at customer’s mobile apps. No plans for web tough :/
Lastly, it means you have to be running Envoy as a sidecar for your apps, which I believe most people will do in the conning years.
(Sorry abou the e-mail, I can demo you what I have as of now, that is why I ask for it)
(Right now stuff I touch tends to use haproxy, varnish, nginx, or Amazon ELB for load-balancing / proxying /routing. No envoy at all.)
Im going to make it clearer about the envoy dependency. I briefly mention mesh network at the bottom, I thought people using service meshes would understand. Definitely adding your feedback.
The core belief of this idea is that many people are going to start using sidecars in their apps, and with solutions like Kubernetes, running 30 versions from the same app should not be a problem (I do it at work).
Im pretty sure the sidecar pattern (service mesh in the buzz word language) is going to be bigger than Docker and Kubernetes, as it allows for even very old code to interact with modern services by using the sidecar.
What problem does this solve? What's so wrong with 'if' statements that makes and external routing engine and a zoo of deployments (and the attendant load-balancing hassle) better?
Let's say you have 500 containers running version A of your app. Now you start to rollout version B, by doing a gradual rollout, you wait for containers with version B to get up before shutting down version A. After 100% of traffic is going to version B, you now start to toggle the new feature using code flags.
Now: what happens if you find a bug after rolling out 300 containers? How fast can you go back to version A? That is the point, you can't assure no bugs are introduced by using code flags, and the rollback process is pretty slow.
I never liked adding toggle code to the apps I write, and after some time using Istio at work, I realized that we can accomplish the same effect by using routing rules in sidecar proxies.
Istio is pretty early and there are no good tools to leverage its full potential, let alone using its routing rules for feature flagging.
I built a visualization for the routes in the service mesh in a couple of days and the people who saw it were pretty happy. I am now working on the creation of flags, where routes are going to be created in the sidecar of each service involved in the feature.
Let me know what you thing, any feedback will be much appreciated!
And its not "Request Demo".... its just submit your email. How do i fall for it every time.
It’s pretty early, I’m going to improve the copy from the feedback received, thanks!
if (CONFIG.registerEnabled) {
...
}
There are a couple of things that bugs me about this:
1. Having a process in place to remove features already validated. It can be fast, but it’s time that could be invested in other things, like improving design, refactoring, etc.
2. Where is the ‘CONGIG’ stored? How do you change/swap them? The code piece might be easy, but changing an environment variable in production at scale? You better have gradual rollout of such config and a rollback strategy. Same things applies if you are relying on an external config server.
Any further data on how you do it will be great!
Let me know if you are interested in the demo, I can show you the product.
As I mentioned, its early, so I didn't put the time to build self-service signups and other things that would allow you to jump into the app.
Feature Flags without writing it in your code.
> How?
Pushing flags to the network layer, leveraging modern networking services.
> Why?
Let you focus on writing business code instead of spend time writing and removing feature flag code.