For the last year or so there has been a lot of interest in the DotNetNuke community about how to run DotNetNuke on Windows Azure. Many people have looked at the problem and could not find a viable solution that didn’t involve major changes to the core platform. This past fall, DotNetNuke Corp. was asked by Microsoft to perform a feasibility study identifying any technical barriers that prevented DotNetNuke from running on Windows Azure. I was pleasantly surprised by what I found and over the course of the next few weeks I’ll present my findings in a series of blog posts. Yes Virginia, there is a Santa Clause, and he is running DotNetNuke on Windows Azure.
- Understanding Azure
- SQL Azure
- Azure Drives
- Web Roles and IIS
- Putting it All together
Part 1: Understanding Azure
Prior to the official launch of Windows Azure, Charles Nurse had looked at running DotNetNuke on Windows Azure. At the time it was concluded that we could not run without major architectural changes to DotNetNuke or to Windows Azure. Since that time several other people in the community have also tried to get DotNetNuke running on Windows Azure and have arrived at the same conclusion. David Rodriguez has actually made significant progress, but his solution required substantial changes to DotNetNuke and is not compatible without also modifying any module you wish to use.
DotNetNuke already runs on a number of different Cloud platforms and we really don’t want to re-architect DotNetNuke just to run on Azure. That approach was rejected because ultimately Azure support is only needed by a small fraction of our overall community. Re-architecting the platform would require significant development effort which could be better spent on features that serve a much larger segment of our community. Also, re-architecting the platform would introduce a significant amount of risk since it would potentially impact every Module and Skin currently running on the platform. The downsides of re-architecting DotNetNuke vastly outweigh the anticipated benefits to a small percentage of our user base.
The Magic of the Fabric Controller
To understand the major challenge with hosting on Windows Azure it is important to understand some of the basics of the platform. Windows Azure was created on the premise that applications running in the cloud should be completely unaware of the specific hardware they were running on. Microsoft is free to upgrade hardware at any time or even use different hardware in different data centers. Any server in the Azure cloud (assuming it has the resources specified by the application service definition) is an equally viable spot on which to host a customers’ applications.
A key aspect of Windows Azure hosting is that the Azure Fabric Controller constantly monitors the state of the VMs and other hardware necessary to run your application (this includes load balancers, switches, routers etc.). If a VM becomes unstable or unresponsive, the Fabric Controller can shutdown and restart the VM. If the VM cannot be successfully brought back online, the Fabric Controller may move the application to a new VM. All of this occurs seamlessly and without the intervention of the customer or even Azure technical staff. Steve Nagy has a great post that explains the Fabric Controller in more detail.
The Fabric Controller is a complex piece of code that essentially replaces an entire IT department. Adding new instances of your application can happen in a matter of minutes. New instances of your application can be placed in data centers located around the world at a moments notice, and they can be taken down just as quickly. The Fabric Controller provides an incredible amount of flexibility and redundancy without requiring you to hire an army of IT specialists or to buy expensive hardware that will be outdated in a matter of months. The costs of running your application are more predictable and scales directly in proportion to the needs of your application.
All of this scalability and redundancy has a price. In order to accomplish this seeming bit of magic, Windows Azure places one giant limitation on applications running in their infrastructure: the application service package that is loaded into Windows Azure is immutable. If you want to make changes to the application, you must submit a whole new service package to Windows Azure and this new package will be deployed to the appropriate VM(s) running in the appropriate data centers.
This limitation is in place for a number of reasons. Because Azure defines their roles as read-only, Microsoft doesn’t have to worry about making backups of your application. As long as they have the original service package that was uploaded, then they have a valid backup of your entire application. Any data that you need to store should be stored in Azure Storage or SQL Azure which have appropriate backup strategies in place to ensure your data is protected.
Also, because every service package is signed by the user before it is uploaded to Azure, Microsoft can be reasonably certain that it has not been corrupted since they first received the package. Any bugs or corruption issues exist in your application because that is what you submitted and not because of some failure on the part of the Azure infrastructure.
Finally, because the role is tightly locked down, your application is much more secure. It becomes extremely difficult for a hacker to upload malicious code to your site as it would require them to essentially break through the security protections that Microsoft’s engineers have put in place. Not infeasible, but certainly harder than breaking through the security implemented by most company IT departments who don’t have nearly the security expertise as the people who wrote the Operating System.
This “read-only” limitation makes it very easy for Windows Azure to manage your application. It can always add a new application instance, or move your application to a new VM by just configuring a new VM as specified in your service description and then deploying your original service package to the appropriate VM instance. If your application instance were to become corrupted, the Fabric Controller wouldn’t have to try and figure out what was the last valid backup of your application as it would always have the original service package safely tucked away.
Because the service package is signed, the Fabric Controller can quickly verify that the service package is not corrupted and that you have fully approved that package for execution. Moving VMs or adding new instances becomes a repeatable and secure process, which is very important when you are trying to scale to 100s of thousands of customers and applications.
Unfortunately, the assumption that applications are immutable is directly at odds with a fundamental tenant of ASP.Net applications: especially those running in Medium trust and requiring the ability for users to upload content to the application. Most ASP.Net applications that support file uploads store the content in some directory located within the application directory. In fact, when running in Medium Trust, ASP.Net applications are prevented from accessing file locations outside of the application directory. Likewise those applications are also prohibited from making web-service calls to store content on external sites like Flickr or Amazon S3.
With DotNetNuke, and other extensible web applications like DotNetNuke, the situation is even more dire. One of the greatest features of most modern CMS’s, and certainly of DotNetNuke, is the ability to install new modules or extensions at runtime. As part of this module installation process, new code is uploaded to the site and stored in the appropriate folders. This new code is then available to be executed in the context of the base application. Given the immutable nature of Windows Azure this functionality just isn’t supported.
The VM Role Won’t Save Us
Last year at PDC Microsoft announced that they would be releasing a VM role that did away with the limitations imposed by the Web and Worker roles in Windows Azure. Many people within the DotNetNuke community who have looked at running DotNetNuke on Windows Azure thought that this would remove the roadblocks for DotNetNuke. With a VM role, instead of supplying a service package that is just your application, you actually provide a .vhd image of an entire Windows 2008 R2 server that is configured to run your application. Any dependencies needed to run your application are already installed and ready to go. This is great as it gives you complete control over the VM and even allows you to configure your application to have read/write access to your application directories. However, when you understand how the Azure Fabric Controller operates, it becomes clear that having control over the VM and read/write access to the application directories doesn’t really solve the problems preventing DotNetNuke from running.
For example, if DotNetNuke was running in a VM role that was running running behind a specific network switch and that switch suffered a hardware failure, the Fabric Controller would want to startup a new VM for your application on another network segment that was unaffected by the outage. Since Azure doesn’t have to worry about having up to the minute backups of your application, it can just reload your original VM image on a new server and have your application back up and running very quickly. If you had been writing data or installing code to the application directories, all of that new data and code uploaded at runtime by your website administrators and content editors would not be present on the original .vhd image you uploaded to Azure.
As you can see the VM Role is not the answer. Don’t despair however. A lot has changed with Windows Azure since Charles Nurse performed his first evaluation and there is a solution. Over the next 4 posts in the series I’ll show you how we solve the immutability problem and get DotNetNuke running in Azure without any architectural changes and just a minimal amount of changes to our SQL Scripts.