I’ve recently posted several articles about the advantages of running network functions on virtualized commodity servers, and while it’s important to make the general case for replacing purpose-built hardware appliances with commodity servers, there’s a more focused story centered around CDNs that’s worth telling.
It involves a slight change in perspective. Rather than view a CDN as one of many services that can be deployed on a virtualized platform—in an earlier article I talked about a spectrum of services ranging from BRAS to CDN—think of the CDN as the platform on which an important subset of network functions are deployed… those related to content delivery. Virtual machines are an enabling technology, but the important point is that a CDN serves as the cornerstone for a rich collection of functions that enable network operators to sell web acceleration solutions to their business and enterprise customers.
In other words, it’s fair to view a CDN as a platform that hosts functions to accelerate B2C and B2B transactions over the Internet, especially transactions that involve cloud-based services. In this scenario, the CDN runs at the edge of the operator’s network, where in addition to caching static objects, it also hosts client-facing and cloud-facing optimizations. The client-facing optimizations, often collectively called front-end optimization, include an assortment of techniques aimed at reducing transaction response time, as well as SSL termination, TCP enhancements for mobile applications, and business logic offload. The cloud-facing optimizations, sometimes called WAN acceleration, include symmetric strategies for compression and de-duplication. (It is notable that these latter techniques are typically symmetric because the CDN provides a point-of-presence both in the data center and at the edge of the network.)
An architecture for CDN-as-a-Platform has two major elements. The first is edge service nodes that not only cache static objects, but also run a policy engine that governs how the CDN interacts with clients that make requests and public/private clouds that host business services. This policy engine receives and processes client HTTP requests, dispatches the request to the appropriate module for processing, and when communication with the data center is required (e.g., to satisfy cache misses or to access dynamic state), selects the appropriate module to optimize communication with those servers. In Verivue’s case, some of these modules are part of the OneVantage product portfolio (some run their own VMs and others are cache plug-ins), while others are provided by third-party service venders (these are typically isolated in their own VMs).
The second element of the CDN-as-a-Platform architecture is the lynchpin—a unified approach to service management. The management suite is responsible for provisioning virtual machines, configuring the services deployed in those virtual machines, proactively monitoring the deployment, and collecting traffic logs for billing and analytics. The core of the management suite is a data model that presents operators with a comprehensive and coherent picture of the available network functions that they must manage.
A clear understanding of this data model is starting to emerge. It includes objects that model the central stake-holders, including CDN Operators, Service Providers, and Content Providers (i.e., business customers); objects that model the deployed infrastructure, including virtual/physical nodes and network interfaces; objects that model the set of services and modules instantiated on that infrastructure; and objects that model the set of policy directives that govern how those services and modules behave.
These rules and policies, in turn, include: (1) routing directives that govern how end-users are routed to the best service node to process a given request, (2) delivery directives that govern how the selected service node delivers the resources named in the request, (3) anchor directives that govern how the service node interacts with cloud-hosted business services that anchor the request, and (4) analytic directives that govern how the service node gathers and processes traffic statistics. In other words, these rules collectively control what service node is selected to serve a given end-user, what module(s) are invoked at that node to customize delivery for that particular user, how those modules are parameterized to serve a particular end-user, and how data is collected.
Coordinating these policy directives across a set of services and modules requires a unifying abstraction that defines the scope for each directive. We call the scope a delivery domain, and it corresponds to the subset of URIs to which a given set of rules and policies is to be applied. A delivery domain is represented (identified) in one of two ways. The first is a CDN-Prefix, which corresponds to the FQDN at the beginning of a URI; it effectively carves out a region of the URI name space to which a set of rules and policies are to be applied. The second is a URI-Filter, which is given by a regular expression; it effectively identifies a subset of URIs belonging to a CDN-Prefix that is to be treated in a uniform way.
In summary, a CDN-powered platform allows business and enterprise customers to accelerate their cloud-hosted web services by effectively extending the cloud from the data center out to the edge of the operator’s network. Service nodes deployed at the network edge provide the optimal vantage point to co-locate caching, front-end optimization, and WAN acceleration technologies, where the management suite plays a central role in coordinating the resulting data center-to-edge cloud on behalf of B2C and B2B customers.
