Well, linkerd was what the article was about, so it's what I was referring to. A "sidecar" sounds like the more established term for what I was calling an ambassador proxy, so it's nice to learn that that's what people call this pattern.
Your explanation sounds a bit "no duh" though, since I can't imagine any way of implementing this pattern that doesn't abstract away knowledge of how to reach remote partners, perform health checks, load balancing, retry logic, etc. It's generally what the term "proxy" implies. Or am I missing something?
Edit: I think my confusion is caused by my experience with running vanilla Mesos (not Marathon or DCOS, but our own custom frameworks), where it's expected that you just have to implement this stuff yourself. I never even thought of open sourcing or productizing what I've written, because I kind of thought that everybody else must be rolling their own quick solutions for these problems too? I admit I'm probably the one with a messed up worldview though.
I think the mesos community is still in the phase of picking the winners for best practices, and hopefully one day it'll be obvious that you use services like linkerd and don't roll your own solution.
Apologies, I didn't mean to sound condescending. I think you got it.
I just wanted to point you to the official explanation, since you seemed to be asking for clarification as to Linkerd's purpose.
A proxy can be a lot of things, of course. Linkerd is explicitly designed to route RPC, not just any web traffic. Linkerd is designed to run close to your app and offload all the routing intelligence.
For example, it seems quite common these days to build many types of service discovery and so on into the app itself: App wants to find another microservice, so it looks up the target host in Etcd or ZooKeeper or whatever, then talks to it, handling retrying and load-balancing and so on. If you're using a DNS solution like SkyDNS or Consul, then the app is isolated from the lookup mechanism, but you're still talking directly to your peer. The opposite, older trend is to use something like HAProxy to handle the routing, but HAProxy was designed for a fairly static set of routing targets.
Linkerd is a bit of a middle way: Make the app stupid and put all the operational intelligence in an external process that isn't actually your app, but still sort of behaves like it is. Linkerd is designed to be dynamically configured to support all the kinds of glue you can think of (ZooKeeper, Kubernetes and so on) so that no app changes are needed to support different routing schemes.
I think I'm just jealous that they're getting attention for solving something that I solved too, but didn't even think to release it because I thought everybody else was just like me.
My approach involves running a sidecar that registers a set of etcd watchers, and when upstream services move around, it passes the list of backends through a config file template (using Go's templating syntax), and runs a configurable command.
Meanwhile, other services' sidecars are health checking them, and keeping them in etcd only as they are healthy.
We wire that up to have the watcher process in the downstream sidecar, which rewrites an haproxy config with the list of upstream backends, and triggers an haproxy restart when it changes the config file.
And then, that whole thing is wrapped in a declarative syntax that lets you say "here's the things I want to talk to", and it knows how to find them in etcd, how to construct the haproxy template, and how to restart haproxy, and puts the whole thing in a docker container that links to your container.
And then we wrap all that in a web UI (and CLI) that lets you say "I want my service to talk to that service" and all the things happen for you.
Looking back, it shouldn't surprise me that this level of effort is something people would want an off-the-shelf solution for. But to be fair, I started doing this a few years back so things like DCOS and Marathon and confd and linkerd and namerd didn't exist then. :-D
Your explanation sounds a bit "no duh" though, since I can't imagine any way of implementing this pattern that doesn't abstract away knowledge of how to reach remote partners, perform health checks, load balancing, retry logic, etc. It's generally what the term "proxy" implies. Or am I missing something?
Edit: I think my confusion is caused by my experience with running vanilla Mesos (not Marathon or DCOS, but our own custom frameworks), where it's expected that you just have to implement this stuff yourself. I never even thought of open sourcing or productizing what I've written, because I kind of thought that everybody else must be rolling their own quick solutions for these problems too? I admit I'm probably the one with a messed up worldview though.
I think the mesos community is still in the phase of picking the winners for best practices, and hopefully one day it'll be obvious that you use services like linkerd and don't roll your own solution.