EPiServer Azure Virtual Path Provider
This blog post is about the EPiServer Azure Virtual Path Provider. This is part of a blog post series on enabling EPiServer CMS to run on Windows Azure. This approach is still experimental and not for production environments.
I’m a strong supporter of the Single Responsibility Principle. Building solutions for Azure is like laying a puzzle. Every piece fits in a specific place with other pieces and together they – hopefully – form a beautiful whole.
Forcing functionality into technologies that don’t quite fit together is a slippery slope. Such an approach usually results in glue and broken pieces.
Our candidate blob storage is fast, it scales beautifully and it’s designed for specifically one purpose: file storage.
“Maverick going supersonic – I’ll be there in 30 seconds”. Anyway, let’s move on.
Windows Azure Blob Storage
Let’s take a quick lap around blob (Binary Large OBject) storage before we dive into the implementation together with EPiServer. A storage account has a limit of 100 terabytes. Let’s read that one again. 100 terabytes. That’s 100 000 gigabytes of storage for our CMS.
One Windows Azure subscription can have – at the time of writing – five storage accounts. Containers can be seen as logical groupings of one or more blobs. Each blob in turn represents a single file. Metadata can be added to a blob – which essentially is a name/value key-pair.
Like most technologies in Windows Azure, blob storage is accessed through a service. This means that we can scale our webrole instances indepently since we are accessing our storage through a single service.
As a new instance of EPiServer CMS spins up it simply calls the blob storage service using the managed API without knowing where or how the files are stored.
And since we’re accessing storage as a service it doesn’t add any restrictions on utilizing the same service together with other systems.
We could for instance share the blob storage with a platform like SharePoint. Both systems can operate independently of eachother and at the same time share data.
Using the Azure VPP
The EPiServer Azure VPP is added like normal VPPs with one exception: blobStorageContainer. This defines which container that should be automatically created and used by the VPP when accessing files in the blob storage. See sample below.
<add showInFileManager="true" virtualName="Azure Global Files" virtualPath="~/AzureGlobalFiles/" bypassAccessCheck="false" name="SiteAzureGlobalFiles" type="DBLOG.Azure.VirtualPathProvider.BlobStorageProvider,DBLOG.Azure.VirtualPathProvider" indexingServiceCatalog="Web" blobStorageContainer="EPiServerCMSAzureVPPGlobal" />
<add showInFileManager="true" virtualName="Azure Documents" virtualPath="~/AzureDocuments/" bypassAccessCheck="false" name="SiteAzureDocuments" type="DBLOG.Azure.VirtualPathProvider.BlobStorageProvider,DBLOG.Azure.VirtualPathProvider" indexingServiceCatalog="Web" blobStorageContainer="EPiServerCMSAzureVPPDocuments" />
It’s important to note that blob storage doesn’t support a traditional way of working with folders. Instead each blob is identified by an URI, e.g. http://storage/accountName/container/myBlobs/blob1.jpg.
The managed API supports creating a query that fetches all blobs at a specific path, e.g. http://storage/accountName/container/myBlobs/. In other words – a folder must contain at least one blob. The VPP creates a “dummy” blob at each URI that should be treated as a folder.
Consider the images below. The first and second is the folder structure in the CMS, the third is the actual structure in blob storage. The fourth shows the image when accessed.
Download & participate
The source code is available at http://episerverazurevpp.codeplex.com. I encourage everyone in the EPiServer community that are excited about running EPiServer on Azure to participate. Drop me a an e-mail and we’ll get you access to the project.