3 ms·

The service mesh is a bit different from an API gateway -- in it's current most popular implementations (linkerd[0] & Istio[1]), there are basically small progr

The service mesh is a bit different from an API gateway -- in it's current most popular implementations (linkerd[0] & Istio[1]), there are basically small programs that run next to each individual instance of the programs you want to run. Linkerd has been around for a while and IMO there weren't that many companies that were at a scale where they needed it (I didn't see it deployed that often), but it's basically that same concept, but on a more granular level -- if you delegate all your requests to some intermediary, then the intermediaries can deal with the messy logic and tracing so your program doesn't have to. A better way to describe is "smart pipes, dumb programs". Imagine that all your circuit-breaking/retry/etc robustness logic was moved into another process that happened to be running right next to the program actually doing the work. You can have both an API gateway and a service mesh deployment -- for example Kong's Service Mesh[2] works this way. They're saying stuff like "inject gateway functionality in your service", but that only make sense if you sent literally every request (whether intra-service or to/from the outside world) through the gateway. Maybe that's how some people used Kong but I don't think everyone thought of API gateways as a place to send every single request through. You'll have a Kong API gateway at the edge and the kong proxies (little programs that you send all your requests through) next to every compute workload. [0]: https://linkerd.io/ https://linkerd.io/ [1]: https://istio.io/ https://istio.io/ [2]: https://konghq.com/solutions/service-mesh/ https://konghq.com/solutions/service-mesh/

jayd16 7y ago
Hmm, is the assumption that, because you're deploying an instance of the mesh as close to the application as possible, you don't need robust logic between the application and the service mesh? I can buy that I suppose.
- hardwaresofton 7y ago
  Yes kind of -- except not in between the application and the service mesh, it's between application and application. Imagine that for every application there is one small binary that runs and serves all it's traffic, like a chauffeur. Your application stops talking to the outside world completely and sends all messages to the small chauffeur binary -- which then talks to other chauffeurs, over the network. Keeping with the chauffeur analogy, there is a "head office" which calls the chauffeurs on CB radio at regular intervals that lets them know which cars go where and how to start them/etc. "head office" => "control plane" "chauffeur" => "side-car proxy"/"data plane" In the end what this means for your application is that you just make calls to external services (whether your own or others) and since all your communication goes through this other binary, you get monitoring, traffic shaping, enhanced security, and robustness for free. Another interesting feature is that if the side-car proxy can actually understand your traffic, it can do even more advanced things. For example you can prevent `DELETE`s from being sent to Postgres instances at the network level.

jayd16 7y ago

Hmm, is the assumption that, because you're deploying an instance of the mesh as close to the application as possible, you don't need robust logic between the application and the service mesh? I can buy that I suppose.

hardwaresofton 7y ago
Yes kind of -- except not in between the application and the service mesh, it's between application and application. Imagine that for every application there is one small binary that runs and serves all it's traffic, like a chauffeur. Your application stops talking to the outside world completely and sends all messages to the small chauffeur binary -- which then talks to other chauffeurs, over the network. Keeping with the chauffeur analogy, there is a "head office" which calls the chauffeurs on CB radio at regular intervals that lets them know which cars go where and how to start them/etc. "head office" => "control plane" "chauffeur" => "side-car proxy"/"data plane" In the end what this means for your application is that you just make calls to external services (whether your own or others) and since all your communication goes through this other binary, you get monitoring, traffic shaping, enhanced security, and robustness for free. Another interesting feature is that if the side-car proxy can actually understand your traffic, it can do even more advanced things. For example you can prevent `DELETE`s from being sent to Postgres instances at the network level.