Apologies, I didn&#x27;t mean to sound condescending. I think you got it.<p>I just wanted to point you to the official explanation, since you seemed to be asking for clarification as to Linkerd&#x27;s purpose.<p>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.<p>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&#x27;re using a DNS solution like SkyDNS or Consul, then the app is isolated from the lookup mechanism, but you&#x27;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.<p>Linkerd is a bit of a middle way: Make the app stupid and put all the operational intelligence in an external process that isn&#x27;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.