Half-time with EPiServer CMS on Windows Azure

This blog post is about EPiServer CMS on the Windows Azure platform. Which possibilities and challenges that lie ahead and how far we’ve come this far.

The Azure story so far

cloud For you that have been reading the EPiServer CMS on Windows Azure blog series know that we have successfully got EPiServer CMS up and running on Windows Azure. By successfully I mean basic functionality of publishing content and working with storage for our Virtual Path Providers.

With the advent of the Windows Azure Virtual Machine (VM) Role we’re going to take a quick breather to get our bearings and reflect on what has been accomplished so far.

EPiServer Azure edition

I’ve simplified EPiServer CMS application architecture into six building blocks in order to relate them to the Windows Azure platform. These are the web application itself, the core CMS application files, the virtual path providers, the EPiServer database, the scheduler service and finally cache management.

This is essentially what we need to have a functional EPiServer CMS website up and running.

Below I’ve mapped these building blocks to their Windows Azure counterparts and highlighted what’s been accomplished so far.

EPiServerAzureMappedArchitectureWe’ve successfully merged the website application with the core CMS application files together with the EPiServer CMS database into SQL Azure.

The Virtual Path Providers are using a temporary solution with virtual drives. An optimal solution would be to implement a virtual path provider that uses the Windows Azure BLOB storage.

At first glance it might seem simple enough. But there are challenges when leveraging EPiServer CMS functionality into these Azure blocks.

Let’s move on to the scheduler service and cache management.

 

Challenges

The power of Windows Azure is that it can scale seamlessly. The application deployed must, however, adhere to loosely coupled architecture principles. Each building block in the Azure environment should be accessed as a service. By doing so they can scale independent of each other.

Scheduler service

The scheduler service is the most daunting task. In EPiServer CMS the scheduler service uses .NET Remoting to start a worker thread in the website running EPiServer CMS. This means that the thread can run in the context of the website. The drawback to this approach is that it can cause significant strain on the website if it’s an expensive operation that’s being performed.

The Windows Azure Worker Role is the windows service counterpart. With the Worker Role we do not have direct access to the website context.

We can use Windows Azure Queues to exchange data between WorkerRole and WebRole to trigger scheduled jobs, alternatively implement WCF services for communication.

The ideal solution would be to implement an EPiServer CMS Worker Role that can perform operations against the Azure BLOB storage and SQL Azure where the actual content of the website is located.

Cache

We’ll want to avoid using the runtime cache since we’re running an unknown number of WebRole-instances. Fortunately the runtime cache implemented by EPiServer CMS can be substituted.

In Windows Azure caching is managed by AppFabric. By implementing a custom cache using the AppFabric we can access the cache as a service and receive a synchronized cache-result independent of how many WebRole-instances we’re running.

License model

The EPiServer CMS license model today demands that you either supply an IP or MAC address to identify the server which the application will be running on. Unfortunately on Windows Azure these are both dynamic.

There is no workaround for this since it would involve breaking the law to circumvent it. Hopefully EPiServer will find a solution to this.

Virtual Machine (VM) Role solution

EPiServerAzureMappedArchitectureVMRole The Virtual Machine (VM) Role is by far the easiest approach to tackle our challenges. Using Microsoft Hyper-V server technology we can create a virtual machine locally, install and configure EPiServer CMS on it and subsequently upload it to the cloud.

The main drawback to this approach is that when we add instances we need to manually configure them as we scale. For example the scheduler service should only be running on one instance when we’ve propagated two.

Also, should the data center where our instances are running suffer a power failure our changes will be lost. Windows Azure will revert to the original image we uploaded.

Roadmap

roadcloud The VM Role is still in Beta and is a closed program. Once it opens for the public we’ll take it for a proper test run.

In the meantime the implementation of Azure BLOB storage and AppFabric are key components to finally having EPiServer CMS powered by Windows Azure.

daniel
daniel
Developer
Recent Posts
Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search