3 ms·

First version is going to be for your Golang server. The routes are anything doable in Envoy, I currently use HTTP headers, but can be URI as well, for instanc

First version is going to be for your Golang server. 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)

stevekemp 7y ago
Mandating the use of Envoy is a pretty big limitation, definitely something you should document. (Right now stuff I touch tends to use haproxy, varnish, nginx, or Amazon ELB for load-balancing / proxying /routing. No envoy at all.)
- andriosr 7y ago
  wow, a ton of good stuff, lets dive in: 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.
lonelappde 7y ago
So I need m^n spearate deployments for n m-valued flags? Wow. 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?
- andriosr 7y ago
  Yes, that's a lot of deployments, but you can't release software in a safer way. 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.

stevekemp 7y ago

Mandating the use of Envoy is a pretty big limitation, definitely something you should document. (Right now stuff I touch tends to use haproxy, varnish, nginx, or Amazon ELB for load-balancing / proxying /routing. No envoy at all.)

andriosr 7y ago
wow, a ton of good stuff, lets dive in: 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.

lonelappde 7y ago

So I need m^n spearate deployments for n m-valued flags? Wow. 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?

andriosr 7y ago
Yes, that's a lot of deployments, but you can't release software in a safer way. 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.