Wednesday 24 March 2010

The Evolution of Application Delivery Part 2: The ADC is born

In "Part 1: Unintelligent" we covered basic Load-balancing. This week we will explore early application delivery implementations.

Some organisations identified there were issues with Load-balancing and invested in Application Delivery Controllers (ADC's hereafter). There are many published articles touting the expression, "Load-balancers are dead!" (Gartner: Load-balancers are Dead). This is precisely what it means. Conscientious corporations rolled out ADC's that would:
a) monitor the service itself e.g., send an out-of-band HTTP request and see if the response is valid - HTTP 200 OK
b) distribute the web clients across the service based on the Connection table, or responsiveness of each individual server

In the event of a server failure (monitor detects a bad response) the ADC would cease distributing traffic to the failed device. This brought forward an enormous change in service uptime, brand protection and resilience.

Maturity in the ADC market added services like SSL Offload: the ADC terminated the encryption and passed the encapsulated payload back to the servers in 'clear', unencrypted form. Server CPU utilisation went down, SSL certificate management (and cost) was reduced and the servers went back to running applications with as much as possible of the Network functions being performed by the ADC.

But there were still problems. The Applications themselves were receiving their Customer requests from a plug-in loaded into a web server. This plug-in delivered unintelligent, unmonitored, round-robin request distribution to the Application Server Tier. Didn't we just solve this problem for the Web Servers??

No comments:

Post a Comment