If you were like me so many years ago, the evolution of load balancing functions, (round-robin, source, and destination hash) were for the most part understandable…but then an evolution started.
Because these functions sat in front of the Web servers, they were able to offload effort from those servers and proxy the conversation with tangible business benefit like less server resources, quicker response times, and ultimately highly available applications.
Then the trusty olde load balancer became more and more Layer 7-biased and we got it to do more things—traffic manipulation, acceleration of HTTP, ipv4 to ipv6 gateways, negative security—and over a period of time we became to know it as an ADC (Application Delivery Controller).
The downside to all of this Layer 4-7 magic was just that. It seemed like magical application stuff to anyone that understood networking and it was equally baffling to the application people as it was all about networking.
I have always described it as voodoo magic, or as a packet mangler. Taking an innocent packet from a browser destined for a Web site and tearing it apart and checking for bad behavior, accelerating its current conversation, and making sure that it always gets to where it needs to go.
The (Unfortunate) Advent of the ADC Island
As we became more and more dependent on these ADC functions (and their reliability, security, and user experience), we ended up in a place called ADC sprawl. And let me tell you that it’s a very unpleasant place to be.
This sprawl is a world of ADC islands that have been created by us to meet the requirements of business owners wanting their own ADC. Sometimes security requirements related to a specific location or a concern about risk caused the need for a separate ADC. Sometimes people wanted a specific placement in the network or the cloud, which meant they each had to have their own ADC as well.
Photo Cred: Oceanhunter.com
Before long, we end up with pairs of ADCs in multiple locations that we sized based on a wet finger or peak flow of traffic. And after a while we quickly realized that the vast majority of users didn’t need the size of the ADC nor the complexity of its function.
This traditional approach to ADC where islands of function are incorrectly sized, expensive, and complex to maintain leads to operational issues. And this is even before the challenge of moving some or all of our applications to the cloud.
A New Approach for ADCs
Instead of this dystopian sprawl, what if we could use a single license that is based on traffic throughput and allows us to allocate as many ADC functions as we like tied back to that throughput allocation, managed by that single license?
Imagine that dystopian world of ADC islands being linked through that license mechanism: An easy means of access, reporting, and control. Think of the possibilities where we can allocate test, dev, and UAT ADC functions at no extra license cost. And when they aren’t in use, we could borrow that allocation for other ADCs that need it.
Ah, I hear the more cynical people ask, “That sounds great, but what are the actual business benefits?”
To which I artfully respond, “The reality is when we right-size our ADC service to the actual throughput required and the ADC features that make sense for that application…and we utilize that bucket of allocation around all of our islands, we see a cost savings in what we pay for that service, along with ongoing support and operational effort. But the real business benefit we get is agility.”
I say it’s time to make a stand and call for a revolution against these egregious outcomes and force ADC services to be easy to use, right-sized, and cost effective—while delivering the functions required in any location and as many of them as we like. And I ask you to do the same, brothers and sisters. Join me and together we will fight for our ADC rights!
For more information on Brocade vADC please click here
