We haven’t expected much from our load balancers in the past. And why should we? Traditional load balancers had a relatively simple job (e.g. distribute traffic, SSL, some content switching), and functioned relatively well. End of story.
But then our infrastructure, platforms, services, and applications got smarter.
The cloud provided us with connectivity and distribution. We began re-factoring and re-architecting. We innovated fast. We had more visibility and control. We had more data (a lot more data—BIG data), and with that data came deep analytics and insights. We began introducing machine learning and artificial intelligence. We innovated even faster. Everything was getting smarter and faster, except for load balancers. We have never expected a load balancer to be a source of intelligence, so they remained… dumb.
It’s time to expect more from our load balancers.
Many in the load balancing and application delivery controller (ADC) space have begun advancing their offering. Several new players also entered the race to create a “smart load balancer”. Many of the offerings are now mature and should be graded across the 9 key functions. I’ll explain the categories and then give a grade to the most popular load balancers available on the market.
We expect our applications and infrastructure to scale to meet demand, so it’s critical that a load balancer do the same. Dumb load balancers are provisioned to address traffic during peak times (think Black Friday or Cyber Monday). What do they do the rest of the year? Idle.
If a model requiring over-provisioning were true of cloud infrastructure, the cloud never would have been adopted. The advantage of cloud-based infrastructure is to elastically scale to meet demand and pay only for what you need/use. This is the smart way to consume IT. Software load balancers like AWS and Avi Networks now provide true elastic load balancing.
You don’t operate in silos anymore. Your load balancer shouldn’t either. When you move applications to new environments, do you have to manually provision or reconfigure your load balancing solution? That’s dumb. Smart load balancers integrate across all your infrastructure and provide hybrid and multi-cloud management functionality.
A smart load balancer is an enabler of hybrid and multi-cloud infrastructure. A dumb load balancer is an inhibitor.
Many organizations still have teams of people responsible for configuring and managing load balancers. This is because many load balancers are dumb and can’t do much without a human in the driver seat.
Smart load balancers can automate deployment and leverage analytics to provide predictive autoscaling so your valuable team members can focus on other critical areas of the business.
With DevOps on the rise, self service is a growing requirement in many IT organizations. Developers now have direct access to the infrastructure and services they need. You’d think the smart thing to do would be to have self-service load balancing too, right? Unfortunately, most load balancing solutions create bottlenecks for DevOps organizations.
The “hurry up and wait” model—submitting IT tickets requesting network administrators to provision, configure, or assist—is dumb. A smart load balancer leverages REST APIs so network administrators can monitor and manage via policy while developers get self service access to the resources they need.
A load balancer stands between your application and the outside world. Being on the front line is an ideal place to be to protect against external threats like a Distributed Denial of Service (DDoS) attack. So why is it that so many load balancers are too dumb to do anything about security?
Modern enterprises requires a smart load balancer that can do more than just usher in the next attack. Smart load balancers can analyze network activity, scan for suspicious interactions, and react to vulnerabilities. Smart load balancers act based off a predefined response or alert administrators if an event is triggered.
Physical load balancers operate in pairs to provide resiliency. If one fails, its teammate is there to back it up. Large organizations that use physical load balancers must manage several of these pairs. The larger the demand for IT resources, the more pairs you need. The danger is that each pair only has one backup appliance in the event of failure.
Smart load balancers don’t need to operate in pairs. Smart load balancers are software-defined and aren't confined to physical appliances. If you need 20 load balancers, you can spin up a team of 20 load balancers (instead of 20 “teams of 2”). If one fails, the other 19 work as a single unit to share the load. Smart load balancers also have self-healing, meaning that the failure would have to outpace the speed of the smart load balancer spinning up new instances.
7. Analytics and Visibility
Load balancers are strategically placed inline with your incoming traffic. That’s the best place to be to identify service failures or performance issues, like latency. Beyond just recognizing an issue is occurring, smart load balancers are capable of identifying the root cause of the issue—the application, network, infrastructure, service, etc.—and applying a predefined response to resolve the issue.
Dumb load balancers don’t assist in troubleshooting the issue. Even some new software-based load balancers from the big infrastructure providers do little to help. If things are working well, you get a green status light. If not, a red status light. New doesn’t necessarily mean smart.
8. Centralized Management
Traditional load balancers have always been necessary point tools in your system, but they were never able to serve as the brain of your system. Dumb load balancers provide little visibility and operate as imperative systems, meaning they require explicit inputs on how they should accomplish their mundane tasks.
Smart load balancers operate as a single fabric across your entire system, creating a centralized management solution. More importantly, smart load balancers are declarative, intent-driven systems. This means that you state what you want the system to accomplish and the solution will deliver. Only a load balancer that serves as a centralized management system (brain) can achieve this.
Cost is primarily determined by whether the load balancer is hardware-confined or software-defined. For your reading pleasure, I’ve outlined why hardware solutions are much more expensive in both text and comic form:
- Proprietary Hardware, Proprietary Software — Hardware is usually more expensive than software, but dumb load balancers require you to buy both the physical appliance and software licenses. The hardware and software are locked to each other and need to be refreshed on a consistent basis. You'll be paying a lot more buying the necessary products and services to achieve the results you need. It's an outdated model.
- Sold in Pairs — High availability is a must. Hardware load balancers have to be sold in pairs in case of failure. If you need 1 load balancer, you'll need to buy 2 appliances. Need 10 load balancers? You’ll be billed for 20.
- Required Over-Provisioning — Physical load balancers can’t scale like smart load balancers. Most companies pay for hardware load balancers for peak periods, like the holiday season, and are left idling for the rest of year (typically only using 10-15% of capacity). Hardware load balancers force you to over-pay to over-provision for an under-performing product. That's dumb.
Based on these categories, I’ve graded the 7 most popular load balancers so you can see their smart score.
Load balancers are the Rip Van Winkle of enterprise IT. For the past 20 years our applications and infrastructure got smarter while load balancers remained dormant… and dumb.
It’s time to expect more from our load balancers.