Designing a content delivery strategy

Technologies like content delivery networks, cloud compute and storage, container schedulers, load balancers, web application firewalls, DDoS mitigation services and many more make up the building blocks that serve the online applications of organizations today. But the entry point to every one of those applications is an often-ignored bit of infrastructure: DNS. As the internet has mushroomed in size and traffic, DNS has adapted to become a critical factor in application delivery. Organizations that rely on content delivery networks (CDNs) can work with their DNS provider(s) to create a CDN strategy that best serves them and their customers.

CDN: the what and the why

A CDN’s job is what it sounds like: deliver content such as images, video, html files and javascript from a network of distributed systems to end-users. CDNs have been around for about as long as Managed DNS companies. Akamai is usually considered the first serious CDN player, and the company rose to prominence during the first dot-com boom. Generally, CDNs deliver content over HTTP or HTTPS, the web protocols, although there are occasionally use cases like video delivery where other protocols come into play.

Early on, the basic motivation to use a CDN was to improve the performance of content delivery.

Imagine an early 2000s web page with a bunch of text and images interspersed. Behind the scenes, to load all the assets for the page, you might need to do a few dozen HTTP requests. (These days that might be more like a few hundred.) Each request requires your browser to connect to a web server, specify the content it’s requesting, download the content, and display the content. If you have users around the world (or even around the country), having them all connect to a single datacenter (say, in Virginia or maybe California) to get the content for your application can work just fine, but if you can move the content physically closer to the application’s end users so each request is done to a web server in the same locale as the user, the time to connect and fetch the content before it can be displayed is reduced.

When better performance is your goal, a CDN can be highly valuable, particularly if your users are widely distributed. If all your users are in New York City, and your application’s “origin” datacenter is also in New York City, there may not be a great performance motivation to use a CDN. But if you also have users around the U.S., in Europe, in Asia or elsewhere, then leveraging a CDN with a wider (ideally global) presence can make the experiences of all those users significantly better.

 Here are two more of the many reasons to use a CDN:

• SSL termination: This use case has become increasingly important. Sometimes, instead of serving static content directly to users, a CDN simply sits between the end user and the application and passes traffic straight through. In these cases, in addition to serving as a buffer against attack, a CDN can handle some aspects of the connection process — like the back-and-forth communication that goes into setting up an SSL-encrypted connection — offloading that work from the application infrastructure itself. Many of NS1’s customers today use CDNs for SSL termination in front of highly dynamic applications like APIs.
• Burstability: Remember the “Slashdot effect”? A CDN has a lot of capacity to handle requests on demand and can handle big bursts of traffic (or even attacks) usually much more effectively than an application’s origin infrastructure.

Creating a CDN strategy

For most CDNs, like any other application, content delivery starts with a DNS lookup to a hostname owned by the CDN (like, say, “client-name.some-cdn.net” or similar). Some DNS providers enables their CDN customers to use that lookup to make the decision about which of their CDN datacenters should fulfill the request.

An intriguing way that a DNS provider can interact with CDNs is by directing traffic across multiple CDNs (the “multi-CDN” use case). For instance, an online gaming company may leverage not just one or two but many CDNs. They do this to optimize performance across challenging markets, to optimize cost (by selecting low/no-cost CDNs for specific end users using network-based traffic management), and to optimize availability by routing around CDN outages. Multi-CDN (and multi-cloud) are rapidly growing use cases that will continue to become more prevalent over the next few years as more companies seek to hedge against service provider outages.

Often, when an organization is talking with a potential DNS provider, the DNS implementation is part of a larger application delivery project. That frequently includes discussion of CDN strategy. For example, an enterprise may be using a contemporary CDN for SSL termination of their application delivery at the edge, and be seeking to bring additional CDNs into the mix to improve performance, optimize cost and maximize reliability. Some CDNs are great for automation, small object delivery, SSL termination and the like; other CDNs are amazing for high-throughput, high-bandwidth applications; and some are legacy CDNs that may not be hyper-modern in their functionality but can be reliable choices for simple enterprise applications.

Acing content delivery

As the world grows hungrier for content of all types—and expects it instantly, from anywhere and at all times—organizations must step up their game in terms of application delivery. Content delivery networks are here to help, and enterprises increasingly use more than one to minimize their exposure to outages. However, there are many CDNs to choose from, each with its strengths and limitations. Work with your DNS provider to define a CDN strategy that addresses the specific needs of your applications and their users.