Yup, makes total sense.<p>I think I&#x27;m just jealous that they&#x27;re getting attention for solving something that I solved too, but didn&#x27;t even think to release it because I thought everybody else was just like me.<p>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&#x27;s templating syntax), and runs a configurable command.<p>Meanwhile, other services&#x27; sidecars are health checking them, and keeping them in etcd only as they are healthy.<p>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.<p>And then, that whole thing is wrapped in a declarative syntax that lets you say &quot;here&#x27;s the things I want to talk to&quot;, 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.<p>And then we wrap all <i>that</i> in a web UI (and CLI) that lets you say &quot;I want my service to talk to that service&quot; and all the things happen for you.<p>Looking back, it shouldn&#x27;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&#x27;t exist then. :-D