Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Friday Blog - Week 22 - SLB, CLB, ALB, Oh my! Load Balancing on Alibaba Cloud

Friday Blog - Week 22 - SLB, CLB, ALB, Oh my! Load Balancing on Alibaba Cloud

If you've been paying attention, you've surely noticed that Alibaba Cloud's "Server Load Balancer" seems to have split in two.

By Jeremy Pedersen

Welcome back! This is the 22nd installment in our Friday blog series. This week, we take a look at load balancing on Alibaba Cloud.

If you've been keeping a close eye on Alibaba Cloud lately, you may have noticed that there have been some changes to the Server Load Balancer (SLB) service.

The SLB service is now divided into ALB (Application Load Balancer) and CLB (Classic Load Balancer), both of which fall under the heading of "SLB" (Server Load Balancer).

What does it all mean? Let's take a (quick) look in this week's Friday blog.

What's the difference between "CLB" and "ALB"?

At a high level, the key difference is that Classic Load Balancer (CLB) uses a hardware load balancer architecture where each load balancer instance is hosted on a single physical machine (or rather a pair of them, in Active-Active configuration to provide high availability). By contrast, Application Load Balancer (ALB) uses NFV (Network Functions Virtualization) to virtualize load balancing functionality across a cluster of machines.

ALB is designed for more sophisticated HTTP and HTTPS load balancing: it can route HTTP or HTTPS traffic based on the Host header field, it can do session-based routing (cookie-based), and it even supports newer protocols like QUIC and Google's gRPC.

All of the Layer 4 (TCP/UDP) and Layer 7 (HTTP/HTTPS) load balancing capabilities originally provided directly as the "SLB" service are now provided by CLB (Classic Load Balancer).

Thus, "SLB" now refers to the entire load balancing service, encompassing both CLB and ALB.

So how should you choose?

  1. If you need to load balance raw TCP or UDP traffic, the choice is obvious: CLB is the only SLB type that supports Layer 4 load balancing.
  2. If you have a need for Layer 7 (HTTP or HTTPS) load balancing, things are a little more complex, but a good general rule of thumb is to simply use ALB for Layer 7 HTTP/HTTPS load balancing, unless you have a very good reason to do otherwise.
  3. If you want to support gRPC or QUIC, again the choice is obvious: you have to use ALB!

### For HTTP or HTTPS, when should I choose ALB?

Pretty much all the time! ALB scales better than CLB, supports more sophisticated routing and filtering rules, and allows you to do traffic mirroring and splitting. Some of the benefits include:

  1. An ALB can support up to 1,000,000 QPS per ALB instance
  2. An ALB instance is spread across multiple backend servers, and can scale as needed
  3. ALB uses more sophisticated rules to decide how to distribute traffic to backend servers, including header, host, and cookie based forwarding rules.

You can learn more about the features and limitations of ALB here.

When would I choose CLB, then?

If you already have a Layer 7 SLB (now "CLB") instance deployed and don't want to change your public IP address or go through the process of cutting over to a new ALB instance, then by all means continue to use CLB.

Another very specific scenario is no-cost, private network load balancing. One of the cool features of CLB is the ability to provide shared-capacity load balancing for free, so long as the load balancer is not accessible from the Internet. Note that this is true only for the "Shared Performance" SLB instance type, in which you share load balancing capacity with other users in your Region and Zone. Dedicated SLB instances still cost money, even if they are private network (VPC-only).

So for no-cost internal SLB deployments, CLB still wins.

You might also want to keep using CLB if you need to have a fixed public IPv4 address associated with your load balancer. By default, ALB instances have a domain name but no guaranteed or "fixed" public IP. CLB instances - on the other hand - always provide a fixed public IP since they are bound to a specific physical machine, unlike the cluster of machines that runs the ALB service.

That's it! You can find more details in the documentation, but the general rules of thumb are:

  1. Choose CLB for Layer 4 (TCP/UDP) load balancing.
  2. Choose ALB (most of the time) for Layer 7 (HTTP/HTTPS) load balancing.
  3. Choose ALB for QUIC or gRPC load balancing.
  4. Choose CLB "Shared Performance" instances for VPC-only internal network load balancing, when cost is critical.

Happy architecting, and see you next time!

I've Got A Question!

Great! Reach out to me at jierui.pjr@alibabacloud.com and I'll do my best to answer in a future Friday Q&A blog.

You can also follow the Alibaba Cloud Academy LinkedIn Page. We'll re-post these blogs there each Friday.

Not a LinkedIn person? We're also on Twitter and YouTube.

slb Server Load Balancer Load Balancer Load Balancing Application Load Balancer Training and Certification ALB CLB Classic Load Balancer
0 1 0
Share on

Read previous post:

Friday Blog - Week 21 - Choosing The Right RDS Or PolarDB Database Instance

Read next post:

Friday Blog - Week 23 - Questions From The Vault

JDP

71 posts | 157 followers

You may also like

Comments

JDP

71 posts | 157 followers

Related Products

More Posts by JDP

See All