There is a gaping hole (which is currently being filled) in the CDN market:  application acceleration.  Application acceleration remains a bit of a holy grail for content delivery networks (CDN), mostly due to the never ending trail of patents and acquisitions in the content delivery industry.  Currently Akamai is the only company to have a hosted application acceleration network, aptly named Web Application Accelerator (WAA). 

Akamai’s approach is a generalized caching and forward mechanism layered on top of their SureRoute platform.  While this is effective en masse, there is a lot of room for targeted improvement.  The knobs and switches provided for WAA are mostly time to live (TTL) settings and other caching options.  Those of us wishing to go for a more controlled, targeted application acceleration network were historically left on our own, working through WAN replication, database sharding, and other “good enough” type solutions.  Thankfully, application acceleration and end user experience management has become a bit of a hot topic in 2008 and now the big networking companies (F5, Citrix, etc) are all developing product lines aimed at accelerating dynamic applications. A potential sleeper in this race is StrangeLoop (well, for .NET applications  anyways [for now?]), whose approach is very easily adaptable for a hosted (CDN) scenario.

In order to convey the approach behind this design I will provide some examples of products currently on the market (which is not an endorsement of any sort).

This approach requires a separation of presentation and data access.  Basically, your front-end webservers (hosting the application you’re trying to accelerate) needs to be able to access a data access tier, who in turn makes requests directly to your data store (usually a database).  This is a very common approach and allows for back-end operations to be managed independently of the front-end.  Typically, messages passed between front- and back-end servers via SOAP or something similar.  If we’re going to push these over WAN, 128-bit SSL is a minimum (alternatively, you could pipe these requests through an SSH tunnel). .

Since the end user’s experience deals largely with your front-end servers, a concept called TCP multiplexing or connection pooling decreases end user render time.  This feature is available on any layer-7 capable load balancer, like the Citrix NetScaler, or the A10 load balancers.  To most effectively utilize a WAN accelerating appliance like the Citrix WANScaler or F5′s WANJet, data access requests from presentation servers should also be multiplexed into one persistent connection back to your data access servers (so you only move large amounts of data between the database and data access, which should be physically near each other).

If possible, the interfaces used for acceleration to origin should be separate from those serving end user requests.

With this approach a company utilizing WAA can reduce their cost of goods sold by only targeting regions where business is conducted.  While there is an upfront investment of hardware, ongoing operations should be much cheaper, with a speedier end user experience.

• Previous Entry: Sticky Sessions and Scalability in the .NET CLR
• Next Entry: High-volume httperf