Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

SDN load balancer debate: Controller or ADC?

Expert David Jacobs discusses whether software-defined networking will render application delivery controllers obsolete or complement evolving SDN.

With the advent of SDN, questions have arisen about the continuing need for application delivery controllers (ADCs)....

ADCs were developed to distribute and balance loads across a group of Web servers. Could SDN controllers take over the role of ADCs -- becoming in effect SDN load balancers-- and thus eliminate their place in the network?

Like an ADC, an SDN controller is capable of monitoring Web servers' individual loads based on queue lengths and processing delays, sending incoming data requests to the least heavily loaded server. If simple load balancing had remained an ADC's sole function, an SDN controller would likely render it obsolete. However, the former can do more than just distribute application demand between servers.

In conventional networking, data flows through the device that makes routing decisions. Because ADCs are located directly in the data path, they can implement application-specific, software-driven functions that are not readily moved to an SDN controller. SDN separates the network control function from data movement, which means an SDN controller can make simple load balancing decisions based on server activity, but not on the contents of the data itself.

ADCs have been -- and continue to be -- delivered as standalone network appliances. Leading vendors have recognized the growth of virtualized systems and the increasing acceptance of SDN, developing virtual ADC implementations in response to this trend. These ADC vendors have formed alliances and integrated their products with virtual network environments, such as those from Cisco, VMware and OpenStack. They have also added script-driven features so network administrators can develop application-specific functions the ADC can execute.

Network security and monitoring

Firewalls, antivirus scanners and intrusion prevention systems have traditionally existed in separate devices. An ADC's location in the data path and its ability to execute application-specific scripts ideally positions it to scan incoming data for malware. Eliminating discrete security components reduces network complexity and capital cost.

Vendors have recognized the growth of virtualized systems... and SDN, developing virtual ADC implementations in response.

ADCs can also protect servers from denial-of-service attacks by blocking problematic requests. A large, distributed attack would likely consume ADC resources, so many legitimate requests would fail to get through, but servers could support the few they did receive.

In addition, ADCs are ideally suited to gather performance and usage statistics due to their location in the data path. They can monitor server delays and also measure traffic by application, by end-user network or by individual end user.

How ADCs improve network efficiency

ADCs can improve network efficiency in ways other than balancing the load. In an environment without an ADC, each end-user browser would create one or more Transmission Control Protocol (TCP) connections to a Web server. Use of network address translation (NAT) in the end-user interface to the Internet reduces the number of connections, but websites managing access from a large number of end-user networks would still be burdened with a very large number of connections. Furthermore, TCP connections are created and torn down for each request, a resource-intensive operation.

Using TCP multiplexing, ADCs establish persistent connections with back-end servers. Individual browsers or NAT functions create connections to the ADC, offloading TCP connection management from the Web servers, and thereby reducing the total number of servers required.

The TCP Slow Start algorithm prevents a new connection from choking the network with an initial burst. By multiplexing TCP connections, Slow Start happens only once. Without an ADC, each browser-to-Web server connection would need to endure the Slow Start process.

Today's Web-based applications commonly require a long sequence of requests and responses. When an initial request reaches a Web server, the server creates a session in which to store information about the request. Simple load balancing might then direct the next set of requests to a different server. The second server creates another session while the session on the initial server times out and is eventually deleted. This is obviously inefficient. ADCs maintain information about ongoing transactions and ensure each subsequent request is directed to the same server.

This technique -- known as session persistence -- is especially critical for supporting Secure Sockets Layer (SSL). With session persistence and TCP multiplexing, ADCs can offload the session creation handshake as well as data decryption and encryption. Without an ADC, Web servers would bear this burden, and without TCP multiplexing, the handshake would need to be repeated each time a session moved to a different server.

Traffic shaping is another way that ADCs improve overall network and application performance. TCP contains mechanisms such as delayed and selective acknowledgement signals (ACKs), adaptive window sizing and explicit congestion notifications. ADCs use these techniques to increase efficiency by reducing bursts and combining short packets into larger ones.

Differentiating servers based on the type of request could improve reliability by simplifying application software. Each application would handle one type of request. Network administrators would supply an ADC script that scans incoming data and directs each request to the application designed to handle it.

ADC vendors are prepared for SDN

ADCs continue to be sold pre-installed in hardware appliances, but the leading vendors, in adapting to SDN, have also developed virtual units that can be quickly inserted in virtualized service chains. These chains, along with other NFV components, can be moved as needed by cloud automation systems.

If the term "software-defined networking" can be extended beyond a controller connected to switches via OpenFlow, then we can certainly consider virtual ADCs -- with enhanced scripting -- as components in an SDN network.

About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.

Next Steps

Brocade plans to acquire virtual ADC product line

Why ADCs are relevant in a programmable world

Get the guide on Buying the right ADC

This was last published in March 2015

Dig Deeper on Software-defined networking

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What role will an ADC play in your SDN environment?
Some great points, David. As you say, if the requirement is simple (unintelligent) load-balancing then sure, the SDN controller can do that. However, if the requirement is for anything stateful and contextually aware - required for performance, availability and security - then thats where SDN controllers fall short. Those who attempt this have found that SDN controllers fail to scale appropriately due to every packet need to route through the controller and not just the session setup information.

A good ADC, with mature API's and scalability, should apply/enforce the logic of the SDN controller while injecting application services to the appropriate message types within the flow.
ADCs improve network efficiency by alternative ways other than balancing the load hence ensuring its significance even in SDN environments as the absence of ADCs deny end-user browsers for, developing Transmission Control Protocol connections to online servers. ADCs also allow the browsers to use Network Address Translation thereby increasing the number of connections to websites without burdening the bandwidth being used. Higher security measures are taken since the TCP connections for each connection are resource-intensive.
I believe the role of ADC in an SDN world will likely revolve around their integration with virtualized systems, through improved scripting for application-specific functions.
I think you have a good point. The divide between traditional network load balancing products and Application Delivery Controllers is growing. SDN could certainly do a good job of switching network traffic between different application servers. Although one very important aspect is deciding on what servers are healthy and least busy at an application layer and what server are performing well at an application layer. So an SDN controller still needs to integrate with the application to change the load balancing rules that then get executed on the switch.

Much of what we do now is related to application delivery, SSL, content rewriting, routing, caching, compression, application health checking, security – the list goes on as ADC’s further mature. Having said that it does not make sense to process all connections at layer7 (Although this can be done at gigabit speed these days (you don’t need layer4 only to shift big data) ) so maybe a good place for an SDN switch is to decide on what traffic would be interesting for the ADC i.e. maybe stuff on 443 need to be sent for decryption etc. All very exciting stuff.