title: What is the conceptual difference between Service Discovery tools and Load Balancers that check node health?
body: <p>Recently several service discovery tools have become popular/"mainstream", and I’m wondering under what primary use cases one should employ them instead of traditional load balancers.</p>
  
  <p>With LBs, you cluster a bunch of nodes behind the balancer, and then clients make requests to the balancer, who then (typically) round robins those requests to all the nodes in the cluster.</p>
  
  <p>With service discovery (<a href="https://www.consul.io" rel="noreferrer">Consul</a>, <a href="https://zookeeper.apache.org" rel="noreferrer">ZK</a>, etc.), you let a centralized “consensus” service determine what nodes for particular service are healthy, and your app connects to the nodes that the service deems as being healthy. <strong>So while service discovery and load balancing are two separate concepts, service discovery gives you load balancing as a convenient side effect.</strong></p>
  
  <p>But, if the load balancer (say <a href="http://www.haproxy.org" rel="noreferrer">HAProxy</a> or <a href="http://wiki.nginx.org/Main" rel="noreferrer">nginx</a>) has monitoring and health checks built into it, then you pretty much get service discovery as a side effect of load balancing! Meaning, if my LB knows not to forward a request to an unhealthy node in its cluster, then that’s functionally equivalent to a consensus server telling my app not to connect to an unhealty node.</p>
  
  <p>So to me, service discovery tools feel like the “6-in-one,half-dozen-in-the-other” equivalent to load balancers. Am I missing something here? If someone had an application architecture entirely predicated on load balanced microservices, what is the benefit (or not) to switching over to a service discovery-based model?</p>