Sergey Nivens - Fotolia

Get started Bring yourself up to speed with our introductory content.

How to buy the best application delivery controller for your firm

Application delivery controllers have advanced in ways that make ADCs more useful for a wider range of companies than ever before. This guide outlines what you need to know in order to buy the best application delivery controller for your company.

From Amazon to Zillow, and anywhere in the alphabet in between, name your favorite website and think about how many web servers sit behind the name ready to handle your transaction. Dozens? Hundreds?

The good news is that you don't need to know.

Application delivery controllers explained

The reason that you don't need to know? Because an application delivery controller (ADC) sits between you and the web server farm to manage the traffic between you and any number of back-end servers. In a nutshell, the ADC controls the delivery of the web application to you -- hence the name.

In the early days of application delivery controllers, the processing demand on these devices was so great that most vendors developed custom ASICs to do the job. This generally translated into high costs, making these devices too costly for smaller organizations. Today, however, processing power has advanced so much that app delivery controllers with sophisticated functionality can be implemented in software and run on cost-effective general-purpose processors. Taken one step further, this allows IT staff to implement today's ADCs not only as standalone hardware devices but quite effectively as virtual appliances or as a hosted service. This can further reduce deployment cost without compromising functionality.

Where a network switch has always been called a network or LAN switch, the same cannot be said of ADCs. In fact, the nomenclature morphed as the functionality increased -- from load balancer, to a Layer 4-7 switch, to ADC.

How it works

In its initial incarnation as a load balancer, an application delivery controller did just that. The device provided a single, front-end IP address that users would interact with. In fact, an ADC would often only handle the inbound request, allowing the web server to respond directly to the client for a more efficient use of resources.

On the back end, the ADC used a variety of algorithms to distribute the incoming users to any number of back-end web servers. That back-end interaction would eventually include some kind of "heartbeat" message between balancer and server. This allowed the load balancer to be sure that it was not shipping off client traffic to a server that had hung or become otherwise unresponsive or unavailable.

Over the years, ADC vendors have leveraged the positioning of the device between "outside" clients and "inside" servers to improve both security and performance.

Finding the best application delivery controller: Features to look for

Given how long ADCs and predecessor technologies have been around, you can comfortably assume a solid core of functionality. In fact, even relatively low-end ADCs are equipped with lots of features. Higher-end ADCs -- those tailored to carriers or data centers with exceptional data demands -- are cloaked with additional features such as IP reputation, application caching and federated identity services. Yet because virtually every feature implemented by an ADC is proprietary, comparing competing ADC products isn't easy.

While the traffic that transits the ADC -- HTTP, FTP, DNS -- is all standardized, there are no standards in place to determine how that traffic is processed. So, shopping by checklist just doesn't work with ADCs. As a result, it's important to test the ADC you're evaluating before you make the decision to buy. Fortunately, most vendors now provide virtual appliances that can be used for this purpose. This makes the feature/function "bake-off" practical for both vendor and prospective customer alike. Read on to see which ADC features belong on your "must-have" list and which are simply "nice to have."

Your application and internet protocol: While it's likely you'll be covered, you still want to be certain that the ADC supports your company's particular set of application needs. While all will support HTTP, perhaps not all will support XML.

Similarly, your company might be planning a migration to IPv6 during the lifetime of this ADC, so be certain that IPv6 support is available.

SSL offload: Ideally, resources on back-end servers should be devoted to providing application services rather than networking housekeeping. Decrypting and encrypting secure socket layer (SSL) sessions can consume significant resources.

Many ADCs will let you offload the SSL burden from individual servers to the ADC. SSL (HTTPS) traffic terminates at the server, while unencrypted HTTP traffic is fed to the back-end servers. Since this takes place within the confines of your data center, there is typically no security concern. The CPU and other resources on the back-end server are now available for application processing rather than being consumed by network security tasks.

HTTP caching: Similarly, application servers can be called upon to send out the same information over and over again. Whether it is a home page or, say, a recent news article, it is not uncommon for hundreds or thousands of users to request the same content in a short period of time.

Many ADCs are smart enough to recognize additional requests for information that have just passed through. That information can easily be cached or retained on the ADC and the ADC can respond to the client by sending data from its cache rather than passing the request on to the target server. Done correctly, this provides a faster response to the user while reducing load on the back-end server.

Of course, you need to be aware of how the ADC determines "freshness" of the data. The last thing you want is for your ADC cache to be sending outdated information to users.

Application monitor: While all ADCs will no doubt offer some version of this functionality, be sure to understand how granular that monitoring goes. Sophisticated monitoring helps ADCs balance their loads more intelligently.

Scalable performance: You don't want to find out that you need to pull and replace an entire device just to get higher performance.

Fortunately, many vendors handle performance upgrades through simple license upgrades. They will sell you a box capable of handling more throughput than you need at the onset and price the license accordingly. If and when you need more throughput, you can upgrade your license without changing or replacing any hardware. Alternatively, if you are implementing your ADC as a virtual appliance or a hosted service (which is also likely to be a virtual appliance), you can likely "spin up" additional ADC resources to meet either spikes in demand or to handle growth in user traffic.

DDoS protection: Distributed Denial of Service (DDoS) attacks can effectively bring down a server just by hitting it with so many bogus requests that it doesn't have resources remaining to handle valid requests.

This same DDoS attack can take down your ADC, making your entire server farm inaccessible. Thus, you will want to be sure that your ADC can fend off DDoS.

Global load balancing: Depending upon your organization and its needs, global capability may be on your must-have list. While this feature can become fairly complex, its goal is to allow your back-end server farm to consist not just of servers colocated with the ADC but also to servers that might be located elsewhere across WAN links.

Virtual appliance: While not a must-have feature, it is always nice to have the option simply to instantiate your ADC as a virtual appliance. Even if you don't intend to deploy the ADC in this manner, having a virtual appliance for testing purposes can facilitate your upgrades and maintenance of your ADC by making it easy to try out new code without it affecting your production ADC.

Data loss prevention: Some ADCs now offer a data loss prevention (DLP) function wherein they inspect outgoing data, compare that data to company policies and either flag or block outgoing data that violates that policy. It is important to remember that DLP can be a very complex function in and of itself and it might not be something that can just be "tacked on" to an ADC.

The bottom line

In the past, application delivery controllers weren't deployed widely but that isn't the case today. If you have even a few application servers -- even if they serve only internal clients -- you should consider deploying an app delivery controller. The costs for entry-level systems are sufficiently low and the benefits to be gained with respect to both improved end-user response time and system availability make ADCs a smart infrastructure investment.

Next Steps

How to benchmark your ADC's performance

How software-defined networking could affect ADCs

Load balancers: Comparing hardware- and software-based options

This was last published in July 2016

Dig Deeper on Network application performance