Service discovery vs load balancing

I am trying to understand in which scenario I should pick a service registry over a load balancer.

From my understanding both solutions are covering the same functionality.

For instance if we consider consul.io as a feature list we have:

• Service Discovery
• Health Checking
• Key/Value Store
• Multi Datacenter

Where a load balancer like Amazon ELB for instance has:

• configurable to accept traffic only from your load balancer
• accept traffic using the following protocols: HTTP, HTTPS (secure HTTP), TCP, and SSL (secure TCP)
• distribute requests to EC2 instances in multiple Availability Zones
• The number of connections scales with the number of concurrent requests that the load balancer receives
• configure the health checks that Elastic Load Balancing uses to monitor the health of the EC2 instances registered with the load balancer so that it can send requests only to the healthy instances
• You can use end-to-end traffic encryption on those networks that use secure (HTTPS/SSL) connections
• [EC2-VPC] You can create an Internet-facing load balancer, which takes requests from clients over the Internet and routes them to your EC2 instances, or an internal-facing load balancer, which takes requests from clients in your VPC and routes them to EC2 instances in your private subnets. Load balancers in EC2-Classic are always Internet-facing.
• [EC2-Classic] Load balancers for EC2-Classic support both IPv4 and IPv6 addresses. Load balancers for a VPC do not support IPv6 addresses.
• You can monitor your load balancer using CloudWatch metrics, access logs, and AWS CloudTrail.
• You can associate your Internet-facing load balancer with your domain name.
• etc.

So in this scenario I am failing to understand why I would pick something like consul.io or netflix eureka over Amazon ELB for service discovery.

I have a hunch that this might be due to implementing client side service discovery vs server side service discovery, but I am not quite sure.

You should think about it as client side load balancing versus dedicated load balancing.

Client side load balancers include Baker Street (http://bakerstreet.io); SmartStack (http://nerds.airbnb.com/smartstack-service-discovery-cloud/); or Consul HA Proxy (https://hashicorp.com/blog/haproxy-with-consul.html).

Client side LBs use a service discovery component (Baker Street uses a stateless pub/sub service discovery mechanism; SmartStack uses ZooKeeper; Consul HA Proxy uses Consul) as part of their implementation, but they provide the health checking / end-to-end functionality you're probably looking for.

AWS ELB and Eureka differ at many points:

Edge Services vs Mid-tier Services
AWS ELB is a load balancing solution for edge services exposed to end-user web traffic. Eureka fills the need for mid-tier load balancing.
Mid-tier server refers to an application server that sits between the user's machine and the database server where the processing takes place in. The middle tier server performs the business logic.
While you can theoretically put your mid-tier services behind the AWS ELB, in EC2 Classic you expose them to the outside world and thereby losing all the usefulness of the AWS security groups.

Dedicated vs Client side Load Balancing
AWS ELB is also a traditional proxy-based load balancing solution whereas with Eureka it is different in that the load balancing happens at the instance/server/host level in a round robin fashion. The client instances know all the information about which servers they need to talk to.
If you are looking for a sticky user session (all requests from a user during the session are sent to the same instance) based load balancing which AWS now offers, Eureka does not offer a solution out of the box.

Load Balancer Outages
Another important aspect that differentiates proxy-based load balancing from load balancing using Eureka is that your application can be resilient to the outages of the load balancers since the information regarding the available servers is cached on the Eureka client.
This does require a small amount of memory but buys better resiliency. The Eureka client gets all the registry information at once and in subsequent requests to the Eureka server, it only receives the delta i.e the changes in the registry information rather than the whole registry information. Also, Eureka servers can operate in cluster mode where each peer is not affected by the performance of other peers.

Scale and convenience
Also, imagine, 1000s of microservices running and each having multiple instances. You will require 1000 ELBs, one for each of the microservice, or something like HAProxy that sits behind the ELB to make layer 7 decisions based on the hostname, etc. and then forward the traffic to a subset of instances. While with Eureka, you only play with the application name which is far less complicated.

Service Discovery component usually has a notification component. It is not a load balancer eventhough some might have the capability to do so. It can notify registered clients about changes, for example a loadbalancer going down.

A client can query a service discovery/registry to get a load balancer that is running. Whereas a load balancer does not noitfy a client when it is down.

You should also read about EUREKA

---

Amazon ELB provides the EC2 instances to your service requests based on Load balancer and the IP addresses of the EC2 instances are not consistent so you can also use EUREKA which does the same job but is based on service registry and client side load balancing in which the Application client for each region has the registry. You can read more about it here : https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance