Azure Load Balancing:

An Azure load balancer is a Layer-4 (TCP, UDP) load balancer that provides high availability by distributing incoming traffic among healthy VMs. A load balancer health probe monitors a given port on each VM and only distributes traffic to an operational VM.

Azure Load Balancing Solutions:

There are mainly 3 load balancing components available in Azure.

· Azure Load Balancer

· Azure Application Gateway

· Azure Traffic Manager

1) Azure Load Balancer

Azure Load Balancer is a Load Balancer in a more classical sense as it can be used balancing load for VMs in the same way we were using traditional load balancers with our on-premise servers. Now since Azure load balancer is designed for cloud applications it can also be used to balance load to containers and PaaS applications along with VMs.

But this similarity with traditional load balancers ends here only mainly because the Azure load balancer actually works are Transport Layer (Layer 4 of OSI model). Which would mean that it will distribute the network traffic in the same Azure data center but will not be able to use the features that tradition load balancers provided at session and application layer since these are the layer 7 constructs of the OSI model.

The load balancer is configured with load balancing rules and it these rules work at the port level. It accepts source and destination ports map them together so that whenever it receives a request for the source port, the request is forwarded to a virtual machine from a group of virtual machines(or application in VNET) attached to the load balancer on the destination port.

Azure Load Balancer can be used in two configuration modes:

· External — Public load balancing

· Internal — Internal load balancing

External — Public Load Balancing

In this mode, load balancer is assigned a public IP address to ensure that the load balancer can accept requests coming in from the internet. The load balancer will get called from the internet by the client applications and services, and then based on the configured rules it will distribute the incoming traffic over VMs, containers, or apps.

Internal — Internal Load Balancing

The internal Load Balancer is essentially the same as external, but it uses a private IP address and thus it can be called only from the applications within the virtual network to which it is attached.

Azure load balancer help us design high availability at the infrastructure level however since there are scenarios where more advanced features and services are required from our load balancing component like connection affinity, security, SSL termination etc we cannot use Azure load balancers are to achieve these advanced features we need a solution that could handle layer 7 constructs of OSI model i.e. application, session etc.

2) Azure Application Gateway:-

Azure Application Gateway is a level 7 load balancer and thus it has access to application and session payload which makes it possible for the application gateway to provide much more feature-packed load balancing like sticky sessions, connection affinity, etc. Since application gateways have more information compared to the Azure load balancer, more complex routing and load balancing can be configured. Application gateway acts as a reverse proxy service. It terminates the client connection and forwards request to back endpoints.

In my opinion, if we are working at an application level where the load balancer should be available publically, there are more use cases in which application gateway makes much more sense to use rather than load balancer.

Application gateway can be thought of (Load balancer ++) that is running on layer 7 and provides more features than load balancer. Application gateway can also be used to route traffic based on URL which is very useful when it comes to developing multi-tenant applications where each tenant had separate instances of VMs running and the tenant identifier comer in the URL.

3) Azure Traffic Manager:

So far, we have seen the load balancing solutions that cater to the load balancing within a data center. load balancers and application gateways are the components that are to be used to achieve high availability within a data center. But with the cloud, we can also architect our applications in such a way that they are geographically distributed. How will we balance the load across geographies then?

Azure Traffic Manager is exactly for this purpose only. Azure Traffic Manager uses DNS to redirect requests to an appropriate geographical location endpoint. Traffic Manager does not see the traffic passing between the client and the service. It simply redirects the request based on most appropriate endpoints. Geographical location endpoints are internet facing reachable public URLs.

Azure Traffic Manager works at the DNS level, i.e. it distributes the load over multiple regions and data centers using the rules configured at the DNS level. The client makes a DNS request and, based on the location of the DNS, Azure Traffic Manager will find the nearest region and sends that back to the client via a DNS response.

Designing Highly Available Apps

When we are designing large scale applications that are highly available, we need to use all these components together. Below image shows a scenario where the application is geographically distributed and is using to choose the nearest region. Then it is using to choose which application server to fetch response from. And finally using a for infrastructure level load balancing for database servers.