Windows Azure Load Balancing: What To Know

On April 16, 2013, Microsoft opened another chapter in its cloud offering by announcing its Windows Azure infrastructure-as-a-service (IaaS) platform, designed and priced to compete directly with Amazon Web Services (AWS). With the release of this new IaaS platform, Microsoft claims to offer customers the ability to move applications easily from traditional on-premises environments into the cloud.

This offering has opened up many exciting possibilities for customers. They can now deploy new virtual machines quickly or migrate existing ones into Windows Azure. What's even more promising is the idea of not having to change the way the applications hosted on these virtual machines work -- no application rewriting, no code updates, and no change to how transactional data is stored.

Virtually all web applications require a load-balancing mechanism for scale-out and high availability. To address this requirement, Windows Azure provides a built-in load balancing layer in its architecture. In fact, the only way to access virtual machines created in Azure from a client machine on the Internet is to send the data via the built-in load balancer.

[Can Windows Azure help your business move to the cloud? Read Microsoft Charges Into Enterprise Cloud Market.]

But incoming connections are load balanced at Layer 4 of the OSI model, which means there is no intelligent awareness of the upper-layer application being load balanced -- traffic is blindly passed. Basic round-robin scheduling (similar to DNS) is the only traffic distribution method available, which often requires specific considerations in the overall application design to provide the correct user experience. Finally, many modern web applications have de facto requirements for persistence and rule-based request steering to keep clients talking to the correct server instance for the entire length of their digital conversation. These concepts are what keep the shopping cart from accidentally being emptied when using online marketplaces. Unfortunately, the Windows Azure load balancer currently doesn't support any type of persistence or advanced rule-based request steering.

These limitations make the original aim -- moving applications seamlessly from the on-premises datacenter to the cloud -- difficult to achieve and results in additional architectural considerations when designing new large-scale production application deployments.

Now, in its defense, Microsoft has stated that as a general rule, "applications should be architected for a cloud environment" -- simplistic, stateless at the network layer, and with transactional awareness across application instances. These are fine ideals when planning new application deployments, but what about all the applications that already exist in a customer's datacenter? These legacy applications may have complex underlying components that cannot easily be given a facelift and, based on their age, may not have even been developed by the customer.

The reality is that many applications exist that require advanced traffic manipulation to ensure that requests are handled on a session-specific basis and delivered to the correct server instance. Updating legacy application architecture generally isn't easy, and with the many day-to-day demands that application admin and engineering teams face, often updates just aren't in the cards.

Is there an easier way? Absolutely! There are products available from Microsoft partners that deliver the functionality missing from the native Azure platform, such as Layer 7 load balancing, application awareness, advanced traffic distribution, session persistence, and application health checking. Such products offer additional ADC functionality that adds tremendous value, such as application protection with an advanced Snort-based intrusion prevention system engine, caching and compression for published services, SSL acceleration, and the ability to share a single endpoint to publish multiple virtual services.

Let's take an example of a web application published through a single SSL endpoint designed for access and use by multiple unique client pools that automatically receive allocation of dedicated resources and environmental components based on the use of host headers. While this may sound like a complex edge case, it's actually a fairly common architecture and would be a daunting and impossible task to cleanly deploy in Azure without re-architecture of the application. Microsoft partners offer application delivery controller (ADC) products that allow you to set up a single cloud service in Azure; create all of the required virtual machines, application resources, and necessary advanced load balancing rules; and publish them without breaking a sweat. This provides you with a single point of entry to your IT environment, simplifies infrastructure management, and reduces overall cost by consolidating the amount of endpoints needed.

Windows Azure provides customers with flexible deployment options for their applications, but there still are limitations that must be taken into consideration when deciding to migrate to this platform. Microsoft partners and their innovative ADC products can help drive more adoption for the Windows Azure ecosystem.

Want to relegate cloud software to edge apps or smaller businesses? No way. Also in the new, all-digital Cloud Software: Where Next? special issue of InformationWeek: The tech industry is rife with over-the-top, groundless predictions and estimates. (Free registration required.)