2 comments

[ 3.4 ms ] story [ 17.5 ms ] thread
The blog post talks about the ideas for what Linkerd does, but offers little for how and why it actually does it. So I'll take a shot at it.

Linkerd runs a proxy on localhost that all local services speak to, as is being done right now commonly with HAProxy. Linkerd proxy handles all the routing. Service discovery is handled by Zookeeper (or Consul or Kubernetes or Marathon). Based on load and latency statistics, It does client side load balancing to these services, similar to Netflix's Hystrix -- which makes me wonder about how it handles routing to 3rd party services on the clearnet, and what it does for circuit breaking on local or remote services.

Linkerd+Finagle are written in Scala, so running one of these on every app server means running a jvm on every server. Is anyone running this in production and can speak to how heavy the linkerd process is? One of the main HAProxy advantages is its efficiency.

Hey, thanks for the thoughtful comment! Here are some quick answers to your questions:

- Routing to 3rd party services: on the roadmap!

- Circuit breaking: Finagle has some very sophisticated mechanisms for this (see http://twitter.github.io/finagle/guide/Clients.html#circuit-...). The current release of linkerd doesn't really expose a lot of that in the config file, but that's also a subject of future work.

- JVM cost: yup, this is definitely something we are aware of. Fortunately, the JVM is a pretty tunable beast, and like HAProxy, there's a relationship between concurrency and memory supported. In our experiments, we can get healthy performance <(1ms p99) for low concurrency setups in ~120mb. Higher concurrency, of course, requires more memory.

Hope that's helpful. Feel free to email us or to hop into our Slack at any point, of course!