Application Delivery Controllers (ADC) are critical to a smoothly functioning data centre. They provide key functions including server load balancing, monitoring the health of servers and apps; protecting the data center from distributed denial-of-service attacks, performing SSL encryption and decryption; making servers more efficient by managing connections, running specialized application scripts and accelerating applications.
ADCs are the glue that holds the data center network together at the application layer.
When applications move to the public cloud they still need all the services ADCs provide. Going to the public cloud without the critical ADC functions puts applications and service levels at risk. This is especially the case when using a hybrid cloud solution where parts of the application are in the cloud and part stay in the data center.
How do ADCs fit in architecturally in the cloud? Is the public cloud provider responsible for the ADC in the cloud?
Two-Tier Architecture
The best architecture for the ADC in the public cloud is a two-tier structure with the ADC’s functions roughly split between tiers. The first tier, provided by the public cloud provider, handles server load balancing (SLB), directing different customer traffic to the group of virtual servers running the application.
This is a rough SLB function without the refinements of directing traffic based on such factors as server load and latency. The cloud service provider’s ADC just gets the traffic to the group of virtual machines supporting the application. The cloud provider’s ADC also performs the SSL encryption and de-encryption, along with providing the first line of defense against any attackers.
The ADC can also compress and decompress traffic, along with providing authentication services, but this requires coordination with the customer. The first tier ADC is also referred to as the “guard dog” ADC because it protects the cloud’s data center from attacks, or network ADC since it oversees the cloud’s network.
A hardware solution is the best answer for the first tier ADC, since this ADC needs maximum performance to handle the large traffic load. Additionally, SSL processing is best performed in specialized hardware that is available only on a hardware ADC. In the early days of ADCs the SSL processing was done in software but the industry quickly learned that as traffic volume increased the software solution had problems keeping up and added an unacceptable amount of latency. A hardware solution also has the horsepower to fight off large DDoS attacks and perform the guard dog function.
There are several reasons the first tier does not perform the other ADC functions. Performance is the biggest reason. The guard dog ADC needs to concentrate its power directing traffic, performing SSL functions and fighting off attacks. Additional ADC functions such as running individual customer’s scripts can slow down the ADC and will take capacity away from the guard dog function. There is also concern about interactions between different customer scripts. Running individual customer scripts greatly complicates change control and problem determination. Additionally, having different customer’s objects cached on the same ADC can open security holes. For these reasons, the first tier ADC should concentrate only on key functions and leave customer specific tasks to the next level.
Second Tier
The second tier ADC, referred to as the tenant ADC, sits in front of a particular customer’s VMs and applications. There can be either one ADC for all the customer’s applications or one per application. The second tier ADC performs the detail SLB function. It balances the load to individual VM’s based on real time response time and load. It also reports server health information back to the enterprise. It runs any application specific scripts along with performing the application acceleration functions such as object caching and server offload functions. It is also a second line of defense.
There are several advantages to performing these functions in an ADC dedicated to just one customer or application. The biggest advantage is that it gives the customer control over the ADC. The enterprise controls when scripts are updated and can quickly fall back if there are any problems. It provides isolation from other customers or applications. When the ADC is brought down, such as when the application is moved from the cloud provider, all the cached information disappears, providing better security.
Enterprises may want the second tier ADC to match the ADC they have at their data center. It is not important that the first tier ADC be the same brand as the ADC used by the enterprise. The reason is that the first tier ADC is transparent to the enterprise and performs only general functions. The second tier ADC is a different story and it may be best to have the same brand ADC since it can simplify integration and operations plus scripts can move seamlessly from the enterprise’s ADC in the data center to the cloud. While it is not necessary that the second tier ADC be the same brand it is something to consider.
Second Tier Form Factor
Cloud providers are starting to offer the second tier ADCs as an extra cost option on their menu of services. While some cloud providers may have a limited menu, offering just one option, other cloud providers will offer a range of options in how they implement the ADC and the vendor solutions they offer.
The options range from a software ADC running on a server, either as a standalone server or in a virtual partition; a dedicated hardware ADC or an instance running in a partition on a hardware ADC. The dedicated hardware option will have the fewest vendor choices available because of the cost to provision different vendor ADCs complicates the cloud providers life and is more than likely the most expensive.
An increasingly common option is to use a software ADC running on a server. This option allows the cloud provider to offer a wide range of options in both performance range and vendors offerings. Most ADC vendors provide this virtual option including A10, Array, Citrix, Coyote Point, F5, Kemp, Radware and Riverbed through its Zeus acquisition. Brocade plans to have a software ADC available during the first part of 2012.
There are no major drawbacks in using a software ADC in the second tier. Since it is not doing the heavy lifting there is no real performance issue to be concerned about. All the ADC vendors claim that performance is not an issue and all the evidence points to accepting their assurances.
At this point, it is not clear if the cloud vendors will provide the full range of vendor solutions. More than likely they may only offer a few preferred vendors. It is also not clear how much customization they will allow to be run on the second tier ADC the enterprise selects from their menu or how much control of the ADC they turn over to the enterprise.
The limited choices and control issue leads to another option – the “bring your own” ADC option. Enterprises load a software version of the ADC they use at their data center onto a virtual machine at the public cloud just as they would an application. This option gives the enterprise complete control over the second tier ADC. It also allows the enterprise to fit the cloud ADC into the global load balancing functions provided by many ADCs and deploy any customization they have. The primary issue is fitting it into the public cloud provider’s infrastructure.
While cloud providers may prefer that customers select something off their menu they should also work to accommodate the “bring your own” ADC by working through any technical configuration issues. How much cloud vendors accommodate “bring your own” varies greatly and should be checked out before signing an agreement.
There are several criteria to consider when selecting the second tier ADC. First, all the criteria used in selecting an ADC for your data center applies. Don’t assume that the software ADC has the same feature set as the hardware ADC. While many do, it is not guaranteed.
Additionally it should be easy to scale the performance of the ADC including going beyond just one instance, as many software ADCs have performance limits well below their hardware versions. One of the reasons for using the cloud is because of variable throughput. If the amount of throughput needed is unknown then look for a solution that can easily accommodate greater throughput and where the cost tracks throughput.
ADC in the Cloud
One of the criteria in selecting a public cloud provider should be how well they have developed their ADC structure and how easy it is to integrate with the enterprise’s ADC needs. The ADC is not a “nice to have” but is critical in supporting enterprise applications.
The ADC architecture outlined for a public cloud provider applies equally to a private cloud design, especially for large data center. The two tier approach provides the flexibility to scale up and down the data center. Isolating each application’s scripts on its own ADC makes problem determination and updating easier. The two tier approach is the future in ADC architecture for both public and private clouds.
