Kentico 1 on 1 - Discussing CDNs with Andy Thompson
In this Kentico 1 on 1, I talked with Andy Thompson (CTO at Get Started) about his experience with CDNs (Content Delivery Networks) and how his company uses them within their projects. Andy has been developing high performing sites for years and has implemented many solutions with some unique CDN capabilities.
Hi, Andy. First, can you give everyone a little background on yourself and how you got to where you are now?
I started developing websites when I was in high school in the late '90s with ASP (Active Server Pages). I was just playing around with early versions of Internet Explorer with ASP. I went to university to study Mechatronics Engineering and Computer Science. It’s kind of niche between embedded computers in machines, so control systems and stuff like that. It sounds like it should be Transformers, but actually, you end up just doing things like suspensions in trucks and stuff. I then had a decision point as to whether to take a traditional engineering career path or go with where my heart and experience were, which was Digital Web. I obviously chose the web and made a career with Get Started. We have specialized in Kentico since 2008. I’ve been CTO and Director here since the start of 2012 and a Kentico MVP since 2015.
Awesome. I know Get Started has a lot of experiences with CDNs. What percentage of your projects use a CDN?
Quite a few at different levels because there are quite a few different ways to use a CDN. At the lowest level, we have a whole bunch of websites offloading things like fonts and common JavaScript libraries like jQuery and third-party utilities like Facebook. They’re all being served from CDN locations. Mainly external libraries that we don’t want to host ourselves, so we reference it straight from a CDN.
At the next level, we have a number of sites that use a CDN to serve their static content. Years ago, it wasn’t as popular, but now we are seeing ten to 20% of our websites pushing all of their static assets to a CDN. That means all of their images, JavaScripts, CSS—all of the stuff that’s not doesn’t include the actual content of the page. That even includes our own website at Get Started.
There are still a couple of websites that go the whole way and serve the entire website, including the actual dynamic HTML and everything, essentially proxying it through a CDN for various reasons. That’s only a very small number of sites, though, as it requires a specific client and content to be able to do that. For those sites, they have a specific design and content that allows us to leverage a CDN to make sure the site performs optimally.
Which CDN do you use the most, and why?
We’re open to using a lot of different CDNs, but the one we have used the most is Rackspace Cloud Files. It’s largely because they have had a node in Australia for some time, backed by Akamai. They have very good tools and support. We actually work with Rackspace quite a bit on hosting, so it fits with our business model nicely.
What is the biggest challenge you face?
Caching. CDN caching is really hard, but it’s not an undefeatable challenge. You just need to adjust your processes because you can’t simply upload a JavaScript or CSS file and have that pushed out everywhere. CDNs will cache those files aggressively because that’s pretty much the point of them. You have to do things like changing the URL to be unique and using cache-busting query strings. Sometimes, we have to log into the CDN directly and clear the cache to make sure a file updated properly.
Do you ever utilize cache expiration policies?
Yes, we do. On all of our sites, we’ll configure the caching the way we need it. Often with CDNs, you are doing that because you need the content to be cached in a very specific manner. That is the whole point of the CND—to cache these files for a long time. You have to accept that some of your files are going to be cached, and we use the expiration policies to fit the caching into how we need the site to work.
What are some of the major things developers need to consider when using a CDN?
Basically, cache control is hard to manage. You need to think about things like file names, time stamps, query string, and headers up front. Also, you need to consider that putting everything in a CDN is not necessarily going to improve your website. You need to consider why you’re doing what you’re doing and how it fits into your strategy. It may make your website slower, based on how you are using it and who your audience is.
What is the most unusual or uncommon use of a CDN you have seen?
There are a couple. In terms of clever rather than unusual, I have seen an Origin Pull CDN (sort of a proxying, caching CDN) used to mask downtime on a site during upgrades and deployments. The site goes down for the upgrade, but the CDN continues to serve the cached HTML until it comes back up. The end users never know about the downtime because the content is continually served from the CDN.
Another interesting use is as an anti-DOS (Denial of Service) system. It uses the CDN like an enormous human shield for the website. Say you have it proxying the site and taking huge amounts of malicious traffic and handling searches. Because it is hosted on a CDN, the traffic is spread out, so there is always content being served. I believe CloudFlare offers this type of solution.
As with any technology, there are several ways to implement a CDN, and Andy and the rest of the Get Started team have definitely seen their share of them. From improving performance to preventing malicious attacks, CDNs can provide tremendous benefits to applications and systems. Regardless of the platform, every company should be looking into how they can improve their applications and leverage all of the capabilities of this powerful technology.