tl;dr 😎

While LBs distribute network or application traffic across numerous servers to improve response times and maximize throughput on the transport and session layers (layers 4 and 5), ALBs operate at a more refined level by routing traffic based on the content of user requests on the application layer (layer 7). Their choice depends on your application’s needs: LBs work well for TCP or UDP traffic with simple, single-tier applications, while ALBs are excellent for complex, multi-tier applications dealing with HTTP/HTTPS traffic.

And the long version… 🤩

In the world of system reliability engineering, load balancing stands as one of the core elements of scalable and reliable application deployment. As a Site Reliability Engineer (SRE), I’ve worked extensively with load balancers and understand their immense importance for modern web applications.

In this post, we are going to dive into the differences between Load Balancers (LB) and Application Load Balancers (ALB), discussing their pros and cons, and usage.

So what is a Load Balancer?

Imagine you’re a package carrier and you have a vast amount of packages to deliver, but there are multiple paths to the destination. The most efficient way to ensure everyone gets their packages on time is to divide the load between the different paths evenly. That’s essentially what a load balancer does in a server environment; it distributes network or application traffic across many servers.

In a broader sense, Load Balancers are hardware or software solutions that maximize the distribution of workloads across multiple computing resources such as servers, networks, and databases. This distribution improves response times, reliability (one of many nodes down? no problem) and maximizes throughput, resulting in a seamless user experience.

What is an Application Load Balancer?

An Application Load Balancer (ALB) is a type of load balancer that goes a level deeper. It operates at Layer 7 of the OSI model (application layer), enabling it to route traffic to back-end servers based on the content of the user’s request. This is a more refined and precise type of load balancing.

Imagine you have a coffee shop and you’ve several employees. Rather than all employees just rotating randomly between the coffee machine and the kitchen, you have a cashier (Application Load Balancer, aka ALB) who accept the initial request, and based on the type of request (coffee or sandwich), that cashier route that requests to a specific employee. One handling the coffee machine (server) and another is back in the kitchen and preparing yummy sandwiches (another type of server). So each has a different role and is being assigned specific requests rather than being “accept all kind of requests”. This ensures that the orders (requests) are handled more efficiently because they are directed to the relevant employee (servers) who specialize in their respective role (request types).

Pros and Cons of Load Balancers and Application Load Balancers

Load Balancer Pros

1. Improved Distribution: The primary benefit of LBs is their ability to distribute client requests or network load efficiently across multiple servers.
2. Scalability: As traffic volume to your application increases, load balancers can efficiently redistribute new client requests to the servers with the least load.
3. Reliability: By distributing traffic across multiple servers, if one server fails, the LB shifts traffic to the remaining operational servers, ensuring seamless service delivery.

Load Balancer Cons

1. Limited routing logic: Classic Load Balancers operate at the network and transport layers. Therefore, they don’t understand anything about the application’s content.

Application Load Balancer Pros

1. Advanced Routing: ALBs offer advanced routing features based on the application’s content, enabling more efficient distribution of traffic.
2. Flexibility: They are excellent for microservices and container-based applications, as they allow the routing of requests to multiple services using the same domain.

Application Load Balancer Cons

1. Complexity: The level of control and flexibility offered by ALBs also means they can be more complex to set up and manage.

When and How to Use LB and ALB

Choosing between an LB and an ALB often comes down to the type of traffic you’re dealing with and how much control you need over where it goes.

Load Balancers

If you’re dealing with TCP or UDP traffic and have a simple, single-tier application, then a classic Load Balancer may be all you need. It’s relatively straightforward to set up an LB – you only need to specify the listener (which checks for connection requests), the backend pool (the servers that requests are distributed to), and possibly a health probe (which checks the health of the backend servers).

Application Load Balancers

If you have a complex, multi-tier application or are dealing with HTTP/HTTPS traffic, an Application Load Balancer will give you much finer control over traffic distribution. ALB’s advanced rules allow you to route traffic based on factors like the request path or the request’s headers. This control makes ALBs perfect for microservices and containerized applications, where different services might need to handle different types of requests.

Setting up an ALB is a bit more complex due to these extra features. You’ll need to set up listeners and target groups (like the backend pool, but more flexible), and define routing rules that determine how the ALB distributes incoming requests.

So, what did we learn today?

In the grand scheme of web applications, Load Balancers and Application Load Balancers act as diligent employees, ensuring that requests are handled efficiently, improving performance, and ensuring reliability. Understanding the differences between LB and ALB can help you make the most informed decision for your application’s requirements.

The right choice between LB and ALB will depend on your application’s specific needs.