Content delivery networks (CDNs) have been around for about as long as Managed DNS companies. A CDN’s job is what it sounds like: deliver content such as images, video, HTML files, JavaScript, and the like, from a network of distributed systems, to end users. Generally, CDNs deliver content over HTTP or HTTPS, although there are occasionally use cases like video delivery where other protocols come into play.
Why would an application developer use a CDN? There are a lot of reasons, although early on the basic motivation was performance of content delivery. Imagine an early 2000s web page with a bunch of text and a bunch of images interspersed. Behind the scenes, to load all the assets for the page, you might need to do a few dozen HTTP requests. Each one of these requires your browser to:
Connect to a web server
Request the content
Download the content
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.
With this performance motivation, the more distributed your users are, the more valuable a CDN can be. If all your users are in NYC, and your application’s “origin” datacenter is also in NYC, there may not be a great performance motivation to use a CDN. But if you also have users around the US, 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.
There are a number of other motivations for using a CDN. Here are a couple of them:
* 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.
* SSL termination. This is an increasingly important use case. 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 our customers today use CDNs for SSL termination in front of highly dynamic applications like APIs.
NS1 works with CDNs in a number of ways. For one, some CDNs are our customers. A good example is StackPath (formerly MaxCDN) where we are responsible for directing traffic across their global infrastructure. 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). We enable our CDN customers to use that lookup to make the decision about which of their CDN datacenters should service the user doing the request. In fact, this is the use case that inspired NS1 in the first place.
Even when a CDN isn’t our customer, we get involved in directing traffic to the CDN if they are in use by one of our customers, because most of the time, to direct traffic to a CDN (say, for a domain like www.example.com), you’d use a DNS CNAME record to point the domain to the hostname provided by a CDN (say, CNAMEing www.example.com to example-client.some-cdn.net). It’s our job to return that CNAME so the browser can eventually find the IP address of one of the CDN’s systems to connect to.
Very commonly, when we are engaging with a new customer, it is part of a larger application delivery project. That frequently includes discussion of CDN strategy. Beyond our ability to direct traffic to CDNs, because our customers know we work with many different CDNs, they often want to hear our thoughts on which CDNs are best for different use cases. Some CDNs, like Fastly, are great for automation, small object delivery, SSL termination, and the like; other CDNs, like CacheFly, are amazing for high throughput, and high bandwidth applications.
One of the more interesting ways we interact with CDNs is directing traffic across multiple CDNs (the “multi-CDN” use case). We have customers who leverage not just one or two, but something like a dozen CDNs. They do this to optimize performance across challenging markets (by selecting the highest performing CDN using Pulsar), to optimize cost (by selecting low/no cost CDNs for specific end users using our network based filters), and to optimize availability by routing around CDN outages. Multi-CDN (and multi-cloud) are super important use cases that will become more prevalent over the next few years as most companies seek to hedge against service provider outages.
If these use cases are part of your planning for 2018 and beyond, contact us to see what NS1’s intelligent traffic management can do for you.