Cloud Computing is a hot topic. Some say it is already here, most agree that it will be much bigger in the coming years. It is pushed forward by the economic benefits of virtualization and consolidation. Take a heterogeneous data center, full of many kinds of servers, running a myriad of applications and consolidate it into a uniform farm of virtual machines, where each application is services by one or more VMs and you have a cloud, what is called a private cloud. I can see many companies turning to this model to better utilize their computing resources and lower their IT management expenses. Taking the next step and trusting these functions to an external provider—what we call the public cloud—may come at a later time.

Cloud environment provides compute power and storage. For web applications it also provides bandwidth allocation, both inside the data center and towards the end customers. Virtual servers are prone to performance degradation just like physical servers are, and when the load goes up, user experience goes down. An application Delivery Controller (ADC) can be very useful in such an environment bringing several benefits—It can offload the servers by handling TCP connections, compression and encryption, and it can save bandwidth by compressing the content that is sent to the end customers. The load on the servers and on the internal network can be further reduced by utilizing the caching mechanism in the ADC.

A Cloud Provider needs to support many applications at once. For a private cloud it could be several dozen enterprise applications, and for a public cloud it could mean thousands of web applications that are hosted in the data center. To add ADC capabilities for all these applications, he now has two choices: place an ADC device before each and every application (or at least those that would benefit from it), which can be a CAPEX and OPEX nightmare, or place just a few ADC devices and aggregate many applications on each, hoping that they all live happily together and don’t disrupt each other by hogging ADC resources.

One way to tackle this problem is to have a virtual software ADC, running on a VM. This way there can be hundreds or even thousands of virtual ADCs, each serving one application and running under the same Hypervisor as the rest of the data center. I can spot three problems with this approach: one is that the performance of a software ADC is limited and un-predictable, the other is the challenge of managing hundreds and thousands of different instances and the third is the cost associated with running all these extra VMs.

A different approach would be to use a hardware ADC and virtualize it by creating many virtual ADC machines on it. To make it happen one needs to manage its resources in a way that one service does not affect another. There is also a need to afford the cloud provider clients with a way to view and configure their ‘Virtual ADC’ without knowing or interfering with other clients. Once these technical issues are met, the benefits of such a machine are its superior and predictable performance and its relative ease of management, leading to CAPEX and OPEX saving which are critical for hosting or cloud provider.

An ADC would obviously need to interact with the Hypervisor running the VMs. One direction is mandatory—the ADC needs to know when new VMs are made available so he can add them to his load balancing pool. The other direction is more interesting—when the ADC identifies a breach of SLA on one of the services, it can alert the Hypervisor that more VMs are required. And when the load diminishes, it can instruct the Hypervisor to take down VMs to conserve data center resources.

In summary clouds, both private and public are coming and with them a challenge of managing the load of thousands of web applications. An Application Delivery Controller can greatly help in alleviating these loads but it needs to evolve for this environment. Virtual software ADC and Virtualized hardware ADC are two possible solutions, with the latter probably being more optimized for the task.