A Buyer’s Guide to Content Delivery Networks
With increased commoditization in the network applications sector and an ever-increasing focus on bringing all data transport onto HTTP, it is getting harder to differentiate content delivery networks (CDNs) by their application layer capability. No longer is it important for your single service provider to offer you HTTP web object distribution for your static web content and to also be able to provide several transports for flash video streaming (real-time messaging protocol; RTMP), Windows Media (MMS/RTSP), and, perhaps, a little Icecast (ICY) for your audio and video streaming.
Ten or 15 years ago, a CDN was a way to reduce the use (and cost) of long distance/international telecom links for repeatedly delivering content that had already recently been transferred over the link in response to another user request. For example, if I wanted to see CNN’s front page in London, then the page would be copied over the (expensive) long haul trans-Atlantic link, cached in London, and forwarded to me. Any subsequent London user wanting to load CNN’s front page would receive his or her copy from the London cache. This would time out over a few minutes, and a new copy would be copied at that point -- ensuring the London users didn’t miss the latest headline publication.
A cost savings would result because CNN’s server needed a smaller internet connection -- after all, only the first user to pull a page actually got it from his or her server -- thereafter, its network connection remained quiet while the London cache served the stream to the users. This cost savings was the opportunity into which the CDNs positioned themselves.
Over the years, however, CDNs have added quality of service agreements, reporting, and a variety of value-added services. In fact, today it would almost certainly be cheaper for CNN to simply have a fatter pipe connected to its server(s) than to outsource the problem to be managed by CDNs.
CDNs will be quick to point out that the user experience will be better if you use a CDN rather than if you simply have your geographically, centrally located server and a fat pipe.
On top of this, another critical feature that CDNs bring is the ability to invest extensively into their own workflow’s logging and the reports and analytics that can be driven from that data. While each CDN customer will have different interests in this Big Data set, building analytics and reporting is a major undertaking for an individual enterprise. However, for a CDN to do this job once -- but then make it available for hundreds of customers -- there is a valuable centralization of resources that generally can provide CDN clients with much better insight into the success of their content delivery than they could reasonably build for themselves. In a world where content delivery is increasingly being monetized, this is an incredibly important function. CDNs do this very well, and those that provide the critical details that can be trusted and form the basis for a content distribution rights deal become valuable partners for content deals.
Increasingly, simple HTTP servers have dominated the egress of the CDN’s technical buildout strategy. As this domination has become the mainstay of CDN income, the CDNs have found it easier to over provision for HTTP traffic to the extent that -- despite RTMP and RTSP being better, more efficient, and better network-optimized than HTTP -- the savings that these efficiencies bring is dwarfed by the relative operational overhead of making available what is, in effect, a niche capability for a minority component of the CDN’s traffic mix.
CDNs do still use media servers, but this is usually only at an ingress where they help to transmux RTMP or RTSP streaming sources into an HTTP transport. Once this transmuxing is done, then all traffic within the CDN can be delivered from the edges to end users using HTTP, making it a simple job for the CDN to manage these edges.
Note that I talk about HTTP being used for delivery to end users. Internally, many CDNs have their own transport protocols -- typically completely transparent to anything outside the CDN -- but they are geared toward all the benefits of the CDN’s own private WAN and its associated capabilities and optimization. For example, a given CDN might employ internet protocol (IP) multicast, allowing it to update many caches in parallel, or alternatives to HTTP such as SPDY (prolifically used by Google).
Related Articles
CDN-hunters, read this first for an explanation of the basic key performance indicators to explore in order to make the right choice for any size company.
02 Mar 2015
CDNs typically offer helpful services beyond content delivery, but trying to understand those services can be confusing. Here's a cheat sheet to the most common value-add services.
03 Oct 2012
Delivering lower CDN costs, higher quality streaming, and more control for ISPs, Netflix's CDN is a win for all parties involved.
13 Aug 2012
A Content Delivery Summit panel looks at how CDNs can avoid costs such as massive network upgrades while serving an expanding audience.
14 Jun 2012