Load balancing is integral to most application architectures. Off the top of my head, load balancing provides at least the following benefits.
- Scaling. A load balancer sprays incoming requests across a backend pool of servers. Existing servers struggling under the load? Throw more servers into the pool.
- Availability. A load balancer will check the health of pool members, taking servers out of the pool that are unable to service requests. This helps ensure application availability.
- Application layer savviness. A load balancer can perform complex manipulation of application layer traffic. For example, reading deep into a packet payload to make a forwarding decision, re-writing payload, or inserting HTTP headers.
- Application maintenance. Using a load balancer, it’s possible to drain traffic from one pool member to upgrade it, while remaining pool members handle the load. Then upgraded pool members can be added back into the mix.
These features are all part of the normal thought process when an application is on-premises, living on your very own servers. Load-balancing is baked into the equation—the standard way of doing things. I suspect many of you reading this have ops processes that involve steps to take with the load balancer under certain circumstances.
Enter The Cloud
But what happens when your application moves to be partially or entirely hosted in the public cloud? The application architectural requirements are the same. Applications still require scalability, high availability, L7 smarts, and the ability to be upgraded with minimal downtime.
In a cloud context, how those demands are met now has some new options. For instance, what sort of load-balancing services are actually required? If Amazon Web Services is the public cloud you’re considering, is their Elastic Load Balancing service with auto-scaling good enough? Or do you still need a full-featured load balancer like you have on premises? This is a dilemma many enterprise vendors and their customers are facing, although from different points of view.
In the face of public cloud services and the Amazons and Azures of the world wanting to own as much of your enterprise IT budget as possible, how does traditionally on premises technology remain relevant? The answers to this question vary, but are interesting overall. Some thoughts.
- Pricing. Public cloud isn’t free. AWS doesn’t give away ELB services. Costs are a part of the consideration when architecting for cloud-based applications.
- Capability. The integrated public cloud load balancers aren’t, so far, as feature-rich as traditional load balancers.
- Cloud privatization. Why assume public cloud? Private cloud is an orchestrated infrastructure delivery system hosted in-house. A traditional load balancer that can participate in that orchestrated world has a home. A traditional load balancer might even be a catalyst that helps enable cloud, even if public cloud doesn’t end up being a part of the final application design.
- Management. Most enterprises using public cloud are also still hosting some services privately. A load balancer that can span both environments is a good thing for the sanity of operations people.
- Portability. If you move a workload to the public cloud, how easy is it to move it back out again? That’s a complicated question to answer and arguably a strawman. Still, the portability concern is tied in part to how bound a workload is to value-added public cloud services. Not necessarily a problem, but a point to consider during cloud-based application design.
These thoughts are all spawned from a conversation I had with the Citrix Netscaler team recently. Their position is that the traditional load balancer has a home in both the legacy and cloud-based application deployment models. To explore exactly why and how that is, they are having a webinar which I will co-host. I’m going to open up the webinar with a few slides, and then quiz the Netscaler folks in Packet Pushers style as they make their case.
Even if you’re not a Citrix user, this discussion will bring up realistic points to consider at you architect cloud-based application load balancing services.
Register here to attend on March 21, 2017 at 900 PT, 1200 ET, 1800 CET.