3 ms·

I am using docker swarm and I just use overlay network to communicate with other sevices and ngnix on the edge. I am trying to understand where this fits into t

I am using docker swarm and I just use overlay network to communicate with other sevices and ngnix on the edge. I am trying to understand where this fits into the picture. Any thoughts ?

bryanlarsen 9y ago
You need it for "web-scale" (tm). You probably don't need it. But unlike a lot of "web-scale" fads, you can drop this in when you actually do need it, you don't have to worry about it now. So glance at the istio.com home page, and when/if you need any of that, come back and take a closer look.
atombender 9y ago
Envoy/Istio are designed to move logic out of your apps and into the middleware. For example, say your app A makes an HTTP request to app B and app B times out. Ordinarily app A has to build in retry logic (with expontential backoff to avoid dogpiling). Fine if you have a single app, but if you have a dozen microservices, that's a lot of duplicated code. The solution is to let a proxy handle it for you. Instead of A -> B, you get A -> Envoy -> B. Envoy can do things like retrying, name resolution (something more flexible than DNS that can, say, be used to do A/B tests where traffic to B actually gets routed to another instance of B that runs code from a different branch), load balancing, request/bandwidth throttling, circuit-breaking (failing requests when an overload "trips" the breaker), logging, profiling (measuring timings and making them available to, say, Prometheus), tracing (inserting HTTP headers to generate a path so if a request goes A -> B -> C, then C has a complete "stack trace" that can be used for logging), and so on. Istio adds a layer of transparency, at least on Kubernetes. Instead of configuring app A to use a proxy, app A just talks to app B as though there's no proxy at all. In reality, Istio has injected some local network magic in the container to route the traffic through the proxy.
- dominotw 9y ago
  This was awesome explanation, I instantly got it. This should be on their homepage. Thank you.
- mosselman 9y ago
  Thanks a lot, you have explained this very well. Being able to explain something this well and so understandably means you really understand what is going on too.

I am using docker swarm and I just use overlay network to communicate with other sevices and ngnix on the edge. I am trying to understand where this fits into the picture. Any thoughts ?

bryanlarsen 9y ago

You need it for "web-scale" (tm). You probably don't need it. But unlike a lot of "web-scale" fads, you can drop this in when you actually do need it, you don't have to worry about it now. So glance at the istio.com home page, and when/if you need any of that, come back and take a closer look.

atombender 9y ago

Envoy/Istio are designed to move logic out of your apps and into the middleware. For example, say your app A makes an HTTP request to app B and app B times out. Ordinarily app A has to build in retry logic (with expontential backoff to avoid dogpiling). Fine if you have a single app, but if you have a dozen microservices, that's a lot of duplicated code. The solution is to let a proxy handle it for you. Instead of A -> B, you get A -> Envoy -> B. Envoy can do things like retrying, name resolution (something more flexible than DNS that can, say, be used to do A/B tests where traffic to B actually gets routed to another instance of B that runs code from a different branch), load balancing, request/bandwidth throttling, circuit-breaking (failing requests when an overload "trips" the breaker), logging, profiling (measuring timings and making them available to, say, Prometheus), tracing (inserting HTTP headers to generate a path so if a request goes A -> B -> C, then C has a complete "stack trace" that can be used for logging), and so on. Istio adds a layer of transparency, at least on Kubernetes. Instead of configuring app A to use a proxy, app A just talks to app B as though there's no proxy at all. In reality, Istio has injected some local network magic in the container to route the traffic through the proxy.

dominotw 9y ago
This was awesome explanation, I instantly got it. This should be on their homepage. Thank you.
mosselman 9y ago
Thanks a lot, you have explained this very well. Being able to explain something this well and so understandably means you really understand what is going on too.