LBaaS: Load Balancing for the Age of Cloud
Jim Frey is Vice President of Research, Network Management for Enterprise Management Associates (EMA) and is a featured guest blogger.
As organizations embrace the cloud, whether as enterprises looking to transform IT or providers expanding and enriching service offerings, traditional IT/networking technologies must be adapted to fit the form of the new reality. This is certainly true of load balancing (LB) as well as application delivery control (ADC), which has undergone virtualization and software programmability/orchestration evolutions.
One related initiative that is getting steady attention is Load Balancing as a Service (LBaaS). At its most basic, the idea behind LBaaS is to provide load-balancing functionality via software so it can be programmed and added to orchestration via APIs. This is the same basic mechanism of all automated, software-defined approaches across the spectrum of cloudification, from software-defined networking (SDN) to software-defined storage, and even software-defined data centers (SDDC). As such, LBaaS could just as well be called “software-defined load balancing.”
LBaaS is also related to network function virtualization (NFV), in this case network functions associated with load balancers/ADCs. Both rely on virtualization and programmability, but LBaaS is a higher-level service concept, which may (or may not) be implemented using NFV.
Many of the driving forces around the industry wide LBaaS initiative have centered on the OpenStack community, which launched LBaaS Version 1.0 in 2013 as a branch of the Neutron networking working group. That first version included the most basic of load balancing capabilities and established a basic instantiation sequence: Create a pool; create one or several members in the pool; create one or several health monitors; associate the health monitors with the pool; and create a VIP that is associated with the pool. This was useful for demonstration projects and for lightweight internal cloud usage, but it wasn’t meant to be an enterprise-class or carrier-grade alternative to a full-blown industrial ADC.
LBaaS Version 2.0, which is coming as part of the Kilo release of OpenStack (1H 2015), adds much more substantial capabilities, including SSL/TLS termination, support for TLS SNI, and Layer 7 content switching. Additional objectives include TLS client certificates, TLS back-end encryption, UDP support, and Layer 7 content modification. Accomplishing this required non-trivial redesign of the LBaaS architecture, along with Neutron extensions such as the ability to store TLS certifications in the Neutron database. LBaaS v2.0 provides the richness that is needed to meet carrier-grade and cloud operator requirements, in terms of high availability and scalability. For example, the Octavia project aims to provide a reference implementation that is worthy of direct use by cloud operators.
Radware was one of the first independent ADC vendors to embrace LBaaS, in part because it was the first to have fully virtualized its ADC solution, via the Alteon VA product. As part of its Virtual Application Delivery Infrastructure (VADI) strategy, Radware had also already productized and proven an orchestration API and plug-in, known as vDirect. These steps made adapting to support the OpenStack Neutron LBaaS extensions quite straightforward, and Radware has maintained an active presence in the Neutron LBaaS working groups. Other ADC vendors have followed, providing their own driver plug-ins to Neutron LBaaS, and thus allowing OpenStack to deliver on the promise of vendor independence.
But OpenStack isn’t the only game in town. LBaaS is a concept that is relevant to any cloud environment. While OpenStack is gaining momentum, the majority of currently fielded and operational clouds are based on alternative open or proprietary technologies, such as VMware vCloud Director, VMware NSX, Apache CloudStack, or Amazon Web Services (AWS). Recognizing the mixed nature of demand, Radware’s LBaaS solution is, for example, supporting VMware vCloud Director and HP Helion in addition to OpenStack Neutron. Over time, the real test of success for LBaaS solutions will be how consistently LBaaS features are supported across multi-cloud environments and how effectively more advanced ADC/LB features can added in an automated, orchestrated fashion.
Other questions are facing the LBaaS working groups within OpenStack, such as whether to remain within OpenStack or to disconnect themselves and form their own open community. Regardless of how all that plays out, LBaaS is here to stay, and its continued evolution should be of benefit to the broader cloud community, including cloud providers, cloud administrators, and cloud users.
