BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Sitting at the doorway to your applications, an application delivery controller, or ADC, is physically positioned to provide a wide range of performance and security services. In fact, because all application traffic must pass through the ADC device, it has become a convenient location to implement functions never anticipated by early server load-balancer architects.
Today's ADCs have evolved to include intrusion prevention system (IPS), web application firewall (WAF) and advanced analytics technologies. These functionalities are in addition to features such as session optimization, caching and Secure Sockets Layer (SSL) offload, which grew naturally from load balancers.
Application delivery controllers: The Swiss army knife for networking
Before you begin vetting various ADC vendors, it's important to understand what features you need. Because ADCs are incorporated in networks both large and small, what you need will depend upon the size and complexity of your deployment.
Many ADC vendors have been around for more than 20 years. Given that heritage, you might expect a neat and tidy list of features, but that isn't the case. In fact, features vary across vendors, and some lists of capabilities are surprisingly vague. So, pay attention and ask your prospective vendors for details.
Creating your list of application delivery controller features
Let's start with the most fundamental and move to more advanced features. However, the order of importance will vary by organization.
Server load balancing. The core of any ADC is server load balancing (SLB). This is where it all began. At its most basic, it's a Layer 4 function that redirects incoming traffic to back-end servers. Years ago, SLB vendors would tout the various options they employed to route traffic. For example, one vendor would support round-robin distribution, where server 1 is scheduled first, followed by server 2, then server 3 and so on. Another vendor might monitor the load of the target server with an agent program and send traffic to the least busy server.
In addition to managing traffic, SLB usually supports a health check feature, where it will periodically investigate to determine if target servers are responding. After all, sending traffic to an unresponsive server doesn't create happy users.
Surprisingly, ADC vendors today don't focus too much on the specifics of their SLB functionality. While this is arguably an ADC's most important function, it's not easy to get the information you need to make an informed decision.
Using extensive research into the application delivery controller market, TechTarget editors focused on those companies that offer the broadest selection of ADC features -- both through appliances and through software only. Our research included data from TechTarget surveys, interviews and reports from other respected research firms, including Gartner.
With cloud deployments, SLB may be the least important function of your application delivery controller, as that function can be reassigned to a cloud-SLB. Because cloud providers such as Amazon Web Services and Microsoft Azure offer basic server load balancing, it's not necessary for cloud-based ADCs to perform that function.
Instead, that task is performed separately -- perhaps by Amazon's Elastic Load Balancer, or by similar Azure or Google Cloud products. So, if your deployment model is primarily cloud-based, SLB might not be a priority. Keep in mind, however, that SLB delivered by your cloud provider is likely to be much less comprehensive than that offered by your ADC vendor.
Global server load balancing. While this is a more advanced function of an ADC device, it's an extension of the SLB function. Global server load balancing is the same basic function as SLB, but with the target servers connected locally via a LAN, as well as remotely via a WAN. This feature is important to companies with a worldwide user base accessing applications from back-end servers that could be located anywhere.
Application acceleration and optimization. As we reach deeper into application traffic -- up to Layer 7 -- we get into the area where basic server load balancing morphs into an ADC. Here, the ADC inserts itself into the application flow, rather than just redirecting traffic. Most ADCs will have some variation of caching, compression and TCP optimization. A few may also offer traffic shaping.
Caching. ADCs can dynamically serve up content that's frequently requested by clients. This is typically invisible to the application. The ADC is responsible for making sure the content is accurate. Caching can reduce the workload for the back-end server and speed up delivery to the clients.
HTTP compression. As traffic passes back out through the ADC, it can apply standard HTTP compression to reduce payload size and thus improve transmission speed. HTTP compression is rarely benchmarked. Its effectiveness depends upon the content. Don't expect to see huge performance gains from it.
TCP reuse and connection multiplexing. Opening and closing TCP sessions constantly can put a significant -- and pointless -- load on the back-end server. Many ADCs support reusing or multiplexing existing TCP sessions to eliminate that unproductive session overhead.
Traffic shaping. A few vendors may also claim that they can "shape" your traffic. This implies they implement some type of quality-of-service scheme that would prioritize certain traffic over other traffic. This isn't a typical feature for ADCs, and capabilities like these are probably better placed on the WAN interface.
SSL offload. All e-commerce traffic will be HTTPS -- that is, encrypted via SSL. The cryptofunction consumes back-end application server resources. Because the internal network behind the ADC is generally assumed to be secure, it doesn't make sense to have the ADC decrypt the traffic as it enters the data center and then encrypt the responses on the way out.
In addition, cryptofunctions can be processor-intensive. Thus, many ADC vendors will offer hardware cryptography boards on their hardware appliances to assist with this offload.
SSL offload makes a lot of sense to run on the ADC, as it conserves resources on application servers and obviates the need to consider installing cryptohardware on any of the back-end servers.
Another consideration: Crypto has moved beyond SSL, so if you're considering this functionality, ask for details on the vendor's current or planned support for new approaches, such as elliptic curve cryptography and perfect forward secrecy.
IPS. Again, because the ADC is positioned in the network near the edge, some vendors blend in IPS functions, as well. Specifically, they may not promote this as an IPS, but rather as a statement their product can resist attacks such as distributed denial of services.
Other vendors think that implementing IPS in the ADC device is a mistake. They note, and I concur, that a stand-alone IPS is the correct way to filter traffic before it hits the ADC.
Web application firewall. When it comes to security, the inclusion of WAF functionality seems sensible. Because the ADC is inspecting traffic at the application level -- basically deep packet inspection (DPI) -- and there are many attacks leveled via applications, it can't hurt to have another line of defense against threats. Even if your IPS is performing DPI, there might be some threats that slip through the initial line of defense that can be caught by an ADC-housed WAF. Strongly consider using this function.
Some vendors extend the packet inspection to outgoing data. This falls under the area of data loss prevention. Some vendors claim to be able to detect sensitive data that's being exfiltrated and either block it completely or mask it before it's sent out. This isn't a common feature, and when it's present, the implementations could vary considerably, so study the specifics if this is an area of interest.
Performance and throughput throttling. While not a feature per se, throughput is an important consideration. ADCs are resource-intensive. Thus, performance can vary based on the functions running and the hardware or virtual platform on which it's running. The price you pay will likely be linked to the relative performance you get.
Some vendors actually license their product by the throughput levels you desire. Thus, throughput throttling is a deliberate cap on throughput to match the license that you purchased.
Licensing options. Equally important is just how elastic the vendor will be with the licenses you have purchased. As your environment changes and, for example, you migrate more applications to the cloud, your ADC requirements might change. ADCs can be purchased either as hardware appliances, software or virtual instances. To that end, the blend of those devices -- and their throughput requirements -- could change significantly.
So, be certain to confirm how flexible the application delivery controller vendor is when it comes to migrating, for example, your hardware appliance license to a virtual instance. You don't want to pay for licenses you can no longer use and simultaneously purchase new licenses for running on a new platform. You also want to be certain your vendor will allow you to pool your licenses and apply them as needed.
Analytics. While not a feature found in early ADC devices, analytics are now found in many application delivery controllers and can be quite valuable for managing both security and service-level agreements. Again, because much or all application traffic runs through the ADC and because of DPI, the ADC knows the details of the application, it is a relatively easy task for the ADC to capture and analyze data.
Be sure you just don't consider analytics as a check-box item, as the breadth and depth of the analytics and, ultimately, their usefulness could vary significantly across ADC vendor offerings.