All about Cloud, mostly about Amazon Web Services (AWS)

Why use the AWS Application Load Balancer (ALB)?

 2016-08-30 /  406 words /  2 minutes

In 2009 Amazon announced the original Elastic Load Balancer (ELB). On August 11th 2016, the AWS Blog announced the new AWS Application Load Balancer (ALB). This is the first new type of load balancer offered by Amazon since. The original Elastic Load Balancer is now called the Classic Load Balancer (CLB) and collectively they are known as ELBs. With an already existing load balancer, why did Amazon create, and why use the AWS Application Load Balancer (ALB)?

Similarities between Elastic and Application Load Balancers

There are lots of similarities between the different generations of load balancers. Like the original Elastic Load Balancer, the Application Load Balancer is a managed service. They both exposes a DNS name (via Amazon Route 53) which provides a highly available connection point. Connections to the DNS names are routed across all availability zones in an AWS Region. Both the ELB and ALB monitor the endpoint for the?requests and blacklist endpoints which fail the health check. Although each load balancer type providers different metrics, both generated CloudWatch metrics. Finally, both work at both the OSI stack Level 4 (Transport) and Layer 7 (Application).

A Use Case for the new Application Load Balancer

When applications were large and monolithic, running a single application on a single virtual machine (VM) under a single operating system isn’t such a big deal. As organizations adopt microservices?which are typically much smaller, it is inefficient to provide each with it’s own VM. Technologies which can run multiple microservices on a single VM within a container can improve efficiency considerably, but routing requests to those microservices becomes a management headache.

Tools such as CloudFoundry provide a solution by integrating the container management with the routing. The router provides a logical single point of entry, and determines the appropriate host and port for a specific application within a container.

While AWS provides container management via the Amazon EC2 Container Service (ECS), it was still awkward to route messages to the appropriate application in a container instance. The Classic Load Balancer understood some parts of the HTTP protocol, such as cookies, and used them to support session stickiness. The Classic Load Balancer did not support content based routing.

The new Application Load Balancer does support content based routing. It is able to examine an HTTP request and route requests based on the URL. For example, http://192.168.1.11/dvd goes to one set of containers, while http://192.168.1.11/api/book goes to a different set of containers.


Tags:  AWS  Application Load Balancer  ALB  Elastic Load Balancer  ELB  Classic Load Balancer  CLB  Network Load Balancer  NLB  Load Balancer  LB
Categories:  AWS  Application Load Balancer (ALB)  Elastic Load Balancer (ELB)  Classic Load Balancer (CLB)

See Also

 Top Ten Tags

AWS (43)   Kinesis (9)   Streams (8)   AWS Console (5)   Go (5)   Analytics (4)   Data (4)   database (4)   Amazon DynamoDB (3)   Amazon Elastic Compute Cloud (EC2) (3)  


All Tags (173)

Disclaimer

All data and information provided on this site is for informational purposes only. cloudninja.cloud makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.

This is a personal weblog. The opinions expressed here represent my own and not those of my employer. My opinions may change over time.