NOTE: This article is now out of date
I have spent the last two days investigating the potential of Azure as a hosting environment for this Umbraco site. The intention was to wade through the, seemingly endless, documents out there to try and put together a very simple Azure migration article and to remove the need to kep my Virtual server running.
What I got to in the end was nowhere near that.
The initial process of migrating over to Azure from the basic Umbraco website was relatively straightforward - I created a role project attached to the site and published it up, then I used the SQL Migration Wizard to transfer up my SQL Server database. I had a few teething problems early on where some of my views were not being published as content - nothing major, but the real pain point was the 5 - 10 minutes it took to deploy each change to see if everything was working. In contrast, my custom Batch file / MSBuild / Mercurial deployment system will go dev --> staging --> live in no more than a minute. Big downside. I persevered anyhow figuring that once I'd got all of the tweaks and config changes all set up I wouldn't have to go through this pain again.
Now, I always have a dual deployment strategy to test that the deployment itself will work (my staging server). Now, in Azure terms, staging is a different animal, it's a temporary holding area which you can swap around with the live site. This allows you to deploy to staging and do a swap out to minimise downtime. What it does not allow you to do is point at alternative data sources, so it's fine for viewing code but not either testing the database deployment or running any kind of destructive testing.
With this in mind I then set up a test instance as well. This all adds up, so I ended up with three (I felt staging test was rather redundant!) instances of the WebRole for one site. I didn't think much of this at first and was happy to have the site up and running and deployments working. It was once I had the core working I started to notice the cracks...
The WebRole approach to Azure deployment meant that I had to add the Umbraco folders and the media folder to the site project; this was a problem because it meant that if I deployed the code again it replaced the media folder on the production server. If I added any media to the server, I had no way of getting it back to create an adequate copy of the live server for dev (I currently have a rebase script I run that restores server side database changes and pulls back the latest media to match it). This left me in the unenviable situation of having to do all changes locally which kind of killed the point of having a CMS entirely.
Despite changing all the permissions settings, for some odd reason I couldn't edit any of the CSS files. This issue did NOT apply to the Templates - This wasn't too much of a biggie for me as I wouldn't do any design changes outside of source control anyway, but might be annoying for others.
I couldn't quite figure out how this was going to work after the initial deployment. I currently use some handy one-click scripts that ensures I have the latest data on any given environment or that push an altered database up to a holding area where it can be deployed to live - It works extremely well when you have only a few people working on the database. I didn't look into this in detail, but I think I could probably have managed this with manual backups, downloads and restores of the live databse and redeployment to SQL Azure when I made dev changes. There were various alternate options I didn't get around to exploring but they were all much more time consuming than my current process.
After noting down these issues to look at in more detail this morning to try to mitigate / find ways around them. There were various articles about Umbraco Media and Azure, most of them posts without answers. It seemed that blob storage is an option for this but, as it's not baked into Umbraco, it would be more than a little painful.
The Cost of all this
At this point, rather than spend any more time, I wanted to look into my usage (I was experimenting using the free usage that I get as part of my MSDN subscription) and cost it out going forward. It became quite clear that...
- My free MSDN usage would start running out on the cloud service portion in about 6 weeks, maximum - just running this site.
- To run the dual deploy instance strategy that I use would cost me just over £160 a month - about 3 times what I pay currently for my VPS.
- Azure is not an appropriate service for small projects.
Azure's tools are really nice to use, although the deployment is very very slow. The infrastructure seems to be one that scales well for medium / large scale applications upward. It doesn't really cater for the smaller scale at all.
If you are considering it for Umbraco you'd have to be thinking about some pretty hefty deployments to make it worthwhile. The plugin support and cost differences seem to make Amazon's web services a far more attractive option for an Umbraco deployment on the cloud.
For a lean approach to a small business, the most cost effective option is still some kind of VPS. Amazon and Rackspace cloud offerings may be appropriate for certain kinds of product at a smaller scale (but that's an investigation for another day). I would recommend looking for a decent VPS provider where you can get snapshots of your virtual machines taken and restored - this is something my current provider doesn't have - but something I'll be looking for in the future.
Since I first looked at this the structures of both Azure and Umbraco have changed quite significantly.