With much criticism after the Miami Heat lost to the Dallas Mavericks in the 2011 NBA Championships, LeBron James soldiered on. A year later, his much anticipated leadership helped the Miami Heat claim their highly coveted position as the victors of the 2012 NBA Finals.
Far beyond any other criticism that LeBron has received is that he went eight NBA seasons without winning a championship, but he has now earned a ring. In his second season with the Heat, LeBron was not only a complete player, but an undisputed leader of his team who took control of games when he needed to, and played the starring role in bringing a title to Miami.
And, similar to LeBron’s dominance in the last eight seasons, load balancing technology too has gone through its transformative evolution in the last seven to eight years, from the simple web traffic management to a full suite of app delivery solution (that combines the capabilities of app acceleration, app security, deep packet inspection, programmatic app development, and many others).
The application delivery controller (ADC) is in many cases described as the next generation load balancer. ADCs tend to offer features like compression, cache, connection multiplexing, application layer security, SSL offload, content switching combined with basic server load balancing. They also tend to offer more advanced features such as content manipulation, advanced routing strategies, and highly configurable server health monitoring.
However, like Lebron’s eight unsuccessful championship attempts, load balancing too has not achieved the quintessential mainstream reputation in the networking community. It’s still regarded to be the archetypal niche technology that complements the network even though it’s much richer, more intrusive, and more “sticky” than a switch or a router.
But, now after those tenuous times, we are in very different situation. Load balancing not only claims the center attention, but it does so in such an influential fashion with the advent of SDN (Software Defined Networking). Here is a brief refresher on SDN technology, as eloquently described by Ivan Pepelnjak,
Every network devices forward data (packets) from the source to its destination through information configured by a network (control plane) controller. SDN is the network architecture that pioneers the separation of network control from forwarding and is directly programmable by a network controller. A standardized or open-source protocol (like OpenFlow) is used to communicate between the network control and the forwarding plane. The concept brings birth to an idea that anyone’s forwarding devices can be controlled with an open-source network controller (control-plane) running on any low-cost commodity server.
From the surface, SDN looks very much like virtualization (separation/decoupling of control/OS and data/HW) and less on load balancing. But, as we dig deeper, SDN promises to holistically address the growing complexity of networking (many protocols, many different configurations, and various touch points) by providing a more intelligent, more simplified, more robust, more flexible way of “networking.” Mat Mathews of Plexxi (one of the top 25 cutting-edge player in the SDN ecosystem) describes SDN’s pragmatism.
SDN should encompass not only hardware virtualization via a decoupled control plane (e.g. OpenFlow), but also network virtualization via L2/L3 services in edge virtual switches, as well as L4-L7 network services, and finally network orchestration (e.g. OpenStack, CloudStack, etc.).
Load balancing, in essence, is the function of a network device that intelligently and dynamically manages traffic (data path) from the requesters to the destination resources through combinations of smart algorithms. Load balancing can be thought as a smart controller that manages the communication “in the network” and “for the network.” In contrast, SDN controller is thought to have the same function in the network, as described here, by Mike Fratto.
SDN controller can create a physical topology of how nodes are connected and, based on some combination of algorithms, create paths through the network. Finally, the paths are programmed into the devices' forwarding engines. That allows the SDN controller to better manage traffic flows across the entire network and react to changes quicker and more intelligently.
The Open Networking Research Center (ONRC) team coins the idea of load balancing as a network primitive. They describe that a comprehensive load balancing system should consider both the load of the servers (basic load balancing functions) and the congestion of the network. The ideal load balancing is essentially “congestion-aware routing.”
…load-balancing should be an integral property of the network. If we think of the network datapath as implementing a basic small set of plumbing primitives‚ then load-balancing fits nicely into this model.
This system needs to be quick to response, intelligent to decide, adaptable to react to certain network conditions, automated to ensure accurate action, and flexible to evolve based on unique environment. Hence, load balancing has a “big-slice” in the network computation that defines how the network is being controlled, programmed, and managed altogether.
The network services marketplace has a number of well-established load balancing players like F5, A10 Networks, Brocade, Radware and others that built commercial load-balancing products that sit in the path to intercept up to millions of incoming (traffic) requests and distribute them over sets of resources. These specialized vendors have the strategic opportunitiesto establish critical install bases and adoptionsamongst the consumers and further the evolution in SDN solution platforms (as described by Mat Palmer from SDNcentral.com).
SDN relates to datacenter networking – the most financially interesting use cases are where budgets are allocated: SANs, LANs, Firewalls, and Load Balancers... Vendors that initially focus on building point products likely have a better chance atestablishing early SDN revenue (and install base) to use to fund future evolution into a platform…
Brocade (and many other LB vendors) are charging this head-on with a few variations in tactics, hence the focus and specificity to flexibility, interoperability, and programmability of the solution. Zeus Kerravala depicted the Brocade announcement,
I liked the news from Brocade in that it was a well-thought-out, comprehensive solution, or more correctly a set of solutions, that offers its customers choice. We’re so early in the cycle of SDN and OpenFlow that it doesn’t make sense for any customer to lock themselves into one particular vendor or approach. The Brocade strategy would allow its customers to run a traditional network and then implement an OpenFlow-based SDN where it needed to.
Whether it’s the joint agreement between Brocade and NEC, the alliance of HP and F5, or Cisco and…*pause* Cisco (that last one just made me “giggle” a little), one thing is certain, and that is load balancing concept and methodology trumps in a big way in the SDN world, from traffic flow management to understanding the behaviors of applications in the network.
Large cloud service providers (like Yahoo, Amazon, Google) rely on their globally distributed data center networks to optimize data path to ultimately guarantee the lowest response time for their subscribers. Subsequently, Google shared their early lesson in adopting and implementing software-defined network within its network to mitigate bandwidth limitations and latency problems.
Load balancing will continue to evolve to be the ultimate controller where network congestion, location, proximity, latency, server loads, and many others are all part of the system intelligence to minimize the response time in network communication.
With LB (Load Balancing) as LeBron, then SDN is an all-star team with OpenFlow, OpenStack/CloudStack, Network virtualization, and load balancing. And, they are all driving towards the championship ring, which is the ultimate network paradigm.
In conclusion, Mat Mathews from Plexxi said it best, “SDN ought to be a means to an end, not an end in itself.”