4 ms·

The whole point of Linkerd is moving logic out of your app. Linkerd is like a library but, instead of being in-process, it inserts itself between the app and wh

The whole point of Linkerd is moving logic out of your app. Linkerd is like a library but, instead of being in-process, it inserts itself between the app and whatever the app needs to talk to. The app just dials http://foo.svc/ http://foo.svc/, and Linkerd sends the connection to the right place; it doesn't need to know where foo.svc is. Many companies, including mine, already run an internal load-balancer (such as HAProxy) that takes care of routing traffic between microservices. Linkerd replaces this with something that is explicitly designed to deal with inter-app communication. (I believe one way to run Linkerd is as a small sidecar app inside the same Docker container the man app, as opposed to a big central server, which is also a neat way of doing it.) Re "why not a library" — sure, you can build all sorts of discovery, distribution and resilience into the client itself. But that consolidates all of this intelligence into just that client. What if you use multiple languages? What about third-party client libs (e.g. Memcached, Redis, PostgreSQL) that you don't control and that you don't want to reimplement? You'll find yourself reimplementing the same thing over and over. > you can't "drop in" resiliency I recommend reading the documentation, because drop-in resilience is really the whole point. The guys who built Linkerd previously developed Finagle [1], which is Twitter's RPC library, and when they talk about network resilience, they actually know what they're talking about [2]. [1] https://blog.twitter.com/2011/finagle-a-protocol-agnostic-rpc-system https://blog.twitter.com/2011/finagle-a-protocol-agnostic-rp... [2] https://monkey.org/~marius/funsrv.pdf https://monkey.org/~marius/funsrv.pdf

jimktrains2 10y ago
> The whole point of Linkerd is moving logic out of your app. Linkerd is like a library but, instead of being in-process, it inserts itself between the app and whatever the app needs to talk to. The app just dials http://foo.svc/ http://foo.svc/, and Linkerd sends the connection to the right place; it doesn't need to know where foo.svc is. That's just DNS. > Many companies, including mine, already run an internal load-balancer (such as HAProxy) that takes care of routing traffic between microservices. Why not DNS round-robin? > I recommend reading the documentation, because drop-in resilience is really the whole point. Fundamentally, the application itself needs to be resilient. No proxy will make it so. It could help, but it can't do it.
- chrisboulton 10y ago
  > That's just DNS. That's not just DNS. Well, it might be - it depends on your environment. For example: In a world where you have some kind of containerization, or scheduler responsible for deploying your services you typically to have services (or different instances of your services), running on ports determined at runtime. You might solve this with an off-host load balancer, so your frontend applications don't need to worry about it, but now you need to worry about those other things: circuit breaking, retry mechanisms, etc between your application and its middle-tear load balancer. A common deployment strategy for something like linkerd (or Envoy) would be as a sidecar process, on the same host where you don't need to worry about the reliability of the network to talk to a remote service, because something else is taking care of 90% of your concerns for you. > Why not DNS round-robin? There's functionality offered by load balancing at L7 that you can't do with round-robin DNS. You end up having to push that complexity into each service you develop - retry mechanisms, circuit breaking, and routing decisions if you're going to try do green/blue or canary deployments. You might say "solve this with a library", but the reality is you have to reinvent the wheel, you have to keep that library in sync to ensure the behaviour is consistent, and if you're in an organization that develops services in "N" languages, that challenge can be even greater. > Fundamentally, the application itself needs to be resilient. No proxy will make it so. It could help, but it can't do it. Absolutely. Your services still need to be able to fail gracefully, but this just moves the complexity of a whole host of other issues to a single, and common spot.
  - cookiecaper 10y ago
    >That's not just DNS. Well, it might be - it depends on your environment. In short, another problem introduced by containers and not relevant to non-containers. Why can't a container get its own IP and port like everything else? FreeBSD jails do. Why make it opaque and put the "ingress" component inside of k8s or Docker? It'd be reasonable for k8s to act as a DHCP/DNS server, but not to swallow the whole world.
- lobster_johnson 10y ago
  > That's just DNS. No, it's a bit more complicated than that, as chrisboulton explains (so I won't go into detail). You could use a dynamic DNS server such as Consul for discovery, and people do. Last I checked, you still had to fight eagerly caching clients, but that's probably doable. But there's still a host of other issues that Linkerd addresses. Again, I strongly recommend reading about Finagle to understand what this is trying to solve. Another thing Linkerd brings to the mix is instrumentation and tracing. Instead of building this into every single sender and receiver, Linkerd can collect tracing data for you and make it available for other subsystems to ingest, such as Zipkin or Prometheus.

jimktrains2 10y ago

> The whole point of Linkerd is moving logic out of your app. Linkerd is like a library but, instead of being in-process, it inserts itself between the app and whatever the app needs to talk to. The app just dials http://foo.svc/ http://foo.svc/, and Linkerd sends the connection to the right place; it doesn't need to know where foo.svc is. That's just DNS. > Many companies, including mine, already run an internal load-balancer (such as HAProxy) that takes care of routing traffic between microservices. Why not DNS round-robin? > I recommend reading the documentation, because drop-in resilience is really the whole point. Fundamentally, the application itself needs to be resilient. No proxy will make it so. It could help, but it can't do it.

chrisboulton 10y ago
> That's just DNS. That's not just DNS. Well, it might be - it depends on your environment. For example: In a world where you have some kind of containerization, or scheduler responsible for deploying your services you typically to have services (or different instances of your services), running on ports determined at runtime. You might solve this with an off-host load balancer, so your frontend applications don't need to worry about it, but now you need to worry about those other things: circuit breaking, retry mechanisms, etc between your application and its middle-tear load balancer. A common deployment strategy for something like linkerd (or Envoy) would be as a sidecar process, on the same host where you don't need to worry about the reliability of the network to talk to a remote service, because something else is taking care of 90% of your concerns for you. > Why not DNS round-robin? There's functionality offered by load balancing at L7 that you can't do with round-robin DNS. You end up having to push that complexity into each service you develop - retry mechanisms, circuit breaking, and routing decisions if you're going to try do green/blue or canary deployments. You might say "solve this with a library", but the reality is you have to reinvent the wheel, you have to keep that library in sync to ensure the behaviour is consistent, and if you're in an organization that develops services in "N" languages, that challenge can be even greater. > Fundamentally, the application itself needs to be resilient. No proxy will make it so. It could help, but it can't do it. Absolutely. Your services still need to be able to fail gracefully, but this just moves the complexity of a whole host of other issues to a single, and common spot.
- cookiecaper 10y ago
  >That's not just DNS. Well, it might be - it depends on your environment. In short, another problem introduced by containers and not relevant to non-containers. Why can't a container get its own IP and port like everything else? FreeBSD jails do. Why make it opaque and put the "ingress" component inside of k8s or Docker? It'd be reasonable for k8s to act as a DHCP/DNS server, but not to swallow the whole world.
lobster_johnson 10y ago
> That's just DNS. No, it's a bit more complicated than that, as chrisboulton explains (so I won't go into detail). You could use a dynamic DNS server such as Consul for discovery, and people do. Last I checked, you still had to fight eagerly caching clients, but that's probably doable. But there's still a host of other issues that Linkerd addresses. Again, I strongly recommend reading about Finagle to understand what this is trying to solve. Another thing Linkerd brings to the mix is instrumentation and tracing. Instead of building this into every single sender and receiver, Linkerd can collect tracing data for you and make it available for other subsystems to ingest, such as Zipkin or Prometheus.