At SUGCON EU 2016 I presented about the different options of using Content Delivery Networks with Sitecore. At the time, I had been working on a particular task to offload large media items into Azure Blob storage and serve them to via Azure CDN and wrote a number of posts detailing how I achieved this.
One of the options that I presented was utilising Azure CDN to serve your media, allowing you to benefit from Azure’s Geo-located Edge Servers meaning that assets are served from locations closer to your users, your own servers can focus on just delivering content (possibly meaning less content delivery servers and licensing costs) as well as improving browser response times by domain sharding the requests.
Use of Azure CDN will work with any version of Sitecore, and is not specific to Sitecore 8.2 Update-1 which added Azure Web Apps support. In fact, you don’t even need to be hosting your servers in Azure to utilise the CDN service.
I’ve been asked by several Sitecorians about configuring CDN, so I thought I would share a step-by-step guide in setting up Azure CDN with Sitecore.
This wasn’t supposed to be a blog post series, and my original reason for this code was to just offload the hosting of large files. But whilst writing the first draft of the blog post I started to investigate various areas since the potential for this module became greater. It was supposed to stop at part two, but I supposed I suffer from the same thing as most of you: programmers OCD. And so a series is born and expect another post or two to follow until a final solution is attained.
In my previous code I noted that the code did not work with the attach/detach handlers in the Media Library:
This is a continuation of my previous blog post in which we uploaded files into Azure Blob Storage through the Sitecore Media Library. If you haven’t read it yet then first go and do that since this may not make much sense otherwise…
The previous post showed how to upload media files into Azure Blob Storage using a custom pipeline. I started off the post by stating that the requirement was to only store large files in Azure and that was primarily the focus of what we needed to achieve but some small tweaks meant it was possible to store all media in Cloud storage.
We still need to make some small updates to code to allow us to actually correctly link to the media in Azure though, so I’ll present a couple of options we have to do that.
On a recent project we had the requirement to be able to link to large files which the user would be able to download, file sizes could be up to 2GB in size. Far too large to store in Sitecore Media Library, at least in database storage. We had previously used Blob storage in Azure with great success for another (non-Sitecore) site so decided to utilise this again but wanted a seamless, single interface for the user to work with, i.e. everything through Sitecore.
Knowing that Azure has a rich API set and pretty much everything in Sitecore can be hacked into via the pipelines we set on our merry journey.
The following requirements were set in order to help set the boundaries:
- any file uploaded to certain folders would be uploaded to Azure
- any file uploaded and the “Upload as Files” option checked would be uploaded to Azure Blob Storage
There was also an additional requirement to automatically calculate the MD5 of each file which was uploaded. This ties in follows on nicely from my previous post about extending Media Item templates using Glass Mapper. Hopefully the specifics of that post will make more sense after this as well 🙂
There have been a number posts about using Sitecore with a CDN provider and there is even a Sitecore CDN Connector module available Marketplace. Although the benefits of using a CDN provider are fairly well stated, such as reducing load on your server and allowing distributed datacentres, Sitecore itself does a pretty good job with its Media Library and for the vast majority of projects using a CDN may be overkill. Bedsides, there have been various projects I’ve worked on where they did not want the additional expense for little benefit or were unable to use a CDN to due to company policy or project requirements/specifications.
A project I was recently working on was utilising Edge Caching services from Akamai. If you’ve never used this type of service before, you need to re-route requests to your site to Akamai (by changing the DNS entry to point there). You can then configure Akamai as to which type of content should be served from cache and which needs to be forwarded on to your own server. There is nothing else for you to change, i.e. you do not need to provide a different domain prefix for your media items. This was an existing setup to the project from a previous vendor and seemed to work pretty well to meet the clients needs. One of the benefits we lose from not having a different domain name is the ability to domain shard.