mercredi 14 octobre 2015

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.




Aucun commentaire:

Enregistrer un commentaire