Why write another load balancer article?

At the time of writing, I am preparing for my Azure Fundamentals exam. Now I have been working with Azure both in a professional and personal capacity as a developer for some time now. When looking at all the types of services I found the naming conventions of the Azure load-balancing & Gateway products a bit confusing, what they do, and when to use which.

Who might find this useful?

People who are new to Azure or just looking for a quick overview. There are some great references online and the Azure portal does offer a wizard/questionnaire on deciding a load-balancing solution to fit your solution.

What is a load balancer?

A basic use case, say you have a single VM or instance of an application and there are peak traffic times or it is a critical service that if its only instance becomes unavailable bad things will happen. Or you want to set up specific routing rules and security over all your inbound traffic at a regional or global level. This is where a load balancer comes in. It assists with traffic distribution, should an instance of a backend service fail traffic is routed away and sent to the next available healthy instance of that service.

At the highest level, it is a piece of software that routes inbound traffic and distributes it across its backend instances. It can be exposed publicly, privately or both depending on the service. Works with the concept of a frontend and backend where the frontend is either services/machines making calls to it and its backend which are the services or VMs registered with the load balancer to have the traffic distributed to them. It can also act as a single entry point in the system. Note that the types of Azure load balancers you choose would also depend on your system's geographical distribution such as global, single, or multi-region.

The type of protocol the traffic is served over would influence the type of load balancer you choose. This is where the OSI model comes in, even if you are just a developer creating business applications I strongly recommend you get familiar with the OSI Model. For the purposes of this article, we are only interested in layer-4 and layer-7.

For reference:

What will influence the type of solution?

Factors to consider when deciding on a load-balancing solution include:

• Are all the services running in the cloud or is this a hybrid cloud environment?
• Is the traffic being sent to your application over external (public internet) or internal (within the VNet or over VNet peering) or maybe both?
• At which layer of the OSI model(layers 4 or 7) do you require the traffic to be balanced?
• The system's geographical distribution i.e. global, single, or multi-region.

Types of Loadbalancers

At the time of writing, this is the list of load-balancing services and I would like to point out that there is a lot more detail to each of these services I do encourage consulting the official documentation on each, if studied all together it can get overwhelming especially if you have never worked in a cloud environment before. So for now the brief summaries will do.

Layer - 4

Azure LoadBalancer

Most commonly used with a pool of VMs as the backend with features such as routing rules, a traffic manager, port forwarding, and health probes. Here you'd route traffic based on port or IP address. It comes in 3 SKUs: Standard, Basic, and Gateway Loadbalancer.

At the time of writing, there is a Cross-region load balancer feature which is in Preview which enables the load balancer to balance across regions and not a single region.

Layer - 7

Azure Application Gateway

A service that is region specific and must be deployed in a VNET. Its backend can be VMs, Azure App Service and variants, IP FQDN, and in the Kubernetes world on the Standard_v2 and WAF_v2 SKUs, it could be configured as an Azure Gateway Ingress controller to be deployed into your AKS cluster.

Supports auto-scaling, end-to-end encryption, zone redundancy, multi-site hosting URL rewriting, SSL termination, and health probes, and be configured to work with a Web Application Firewall(WAF). Important to point out Application gateway is a single point of entry and can be configured to be public or public + private. What I mean by this is you can't deploy an Application gateway into your VNET and only have private VNET services access it with no public endpoint.

Supports: HTTP/ HTTPS/ HTTP2/ FTP/ SMTP and websockets traffic.

Azure Front Door

It is a global load balancer, here you can add on Azure CDN and WAF. It has 3 SKUs: standard, classic, and premium. Here you would have it handle global traffic and route it down to your region-specific load balancers. Its features are similar to the Application Load Balancer but come with a cache, traffic acceleration, URL rewrite/redirect, DDos protection, end-to-end TLS encryption, and geo-filtering.

This is for when multi-region support is required and the need to manage large amounts of traffic which usually comes with a medium to a large business that requires high availability, redundancy, security, and services being requested from all over the world. Not a service you'd set up for a very small business or side project due to cost.

DNS

Azure Traffic Manager

Is a globally scalable DNS routing service. It would route inbound requests to your DNS alias to the configured routing criteria. The key concept here is that your destination needs to be public.

An example would be you have multiple applications in different regions and maybe some on-premise domains and you want to set up a single DNS record usually a CNAME and have Traffic manager route traffic to each of the configured downstream routes.

Summary

Load balancers assist with security, redundancy, high availability, scaling, encryption, health probes, and routing rules to name a few. I would say it is something to strongly consider in a production environment if the aforementioned attributes are important to your application or customers. You can review Microsoft's more detailed Overview of solutions and how to combine them to get the best load-balancing solution for your system.

Thanks for taking the time out of your busy day to either read or skim over this article, your feedback is most welcome.