Currently we’re in the process of moving our MVC3 application onto Microsoft’s Azure cloud platform. Azure offers a number of compelling features, however, note the asides which dispell some of the marketing smog
- Rapid deployment – A new client website can be deployed more or less instantly, without the need to provision costly equipment from your hoster – or more likely shoe-horn the new site onto your creaking live environment (or is that just us)
- Pay for what you use – small sites can be installed in Small or Extra Small instances and you can pay as little as $0.05 per hour for hosting and $10 per month for a database. Pricing info is here
- Guaranteed 99.95% uptime*
- There are a couple of things to think about here. To get the 99.95 guarantee you have to run a minimum of 2 instances, which obviously doubles your cost. So you need to be aware that costs are not as cheap as they might appear.
- Like most hosters you don’t have a huge come-back if this figure isn’t achieved. According to the SLA (as I read it) you’ll get your money back for the time your site was down, plus 10-25%. Which is small fry compared to potential loss of reputation.
- Scaling up is easy*– as your site grows from a site with a readership like my blog (not even my Mum is interested) to hopefully the next Facebook, it is simple to add extra instances and have your site automatically loadbalanced across them. This method also allows you to deal with traffic spikes, for instance if your site was popular in America you could add instances during peak time and scale it back down at nightime – this would be a lot harder to achieve on traditional hardware.
- Note the * – however, there is a certain amount of marketing hype in the ease of scaling out a site. To achieve the above shangri-la you need to be very aware of session management, and if you’re currently relying on in-memory session management, or sticky sessions on your loadbalancer, your app (like ours) can not immediately take advantage of cloud scaling. There are solutions to this problem, I’ll hopefully get a chance to blog about them in the future.
- Currently you’d need to write your own tooling to automatically spin up new instances in response to demand. This is not a trivial task, and at time of writing documentation on this is reasonbly scarce.
- No OS to worry about– This take a little getting used to, but your app is installed into a Hosted Service or Role. So you don’t need to actually worry about the platform that your app is running on. Microsoft do that for you, so you don’t need to worry about security patches, access rights and all the headaches that go along with managing your infrastructure. This is what sets Azure apart from services like Amazon EC2, which deal with OS images, so patching etc is still a major concern.
- It is possible to RDP onto a particular instance if you need to do a little bit of debugging. But you need to bear in mind, that the whole point of cloud computing is the ability to easily scale up your site, so you should never have to manually configure anything on an instance of your site, as that defeats the point of automatically scaling up to meet demand.
- Easy integration with Visual Studio – If you’re already on the Microsoft stack, Azure fits easily into your workflow. However, you will need to be running Windows Vista or later to work with the toolset.
- Suite of tools for working in the cloud – In addition to the web hosting, Azure offers a CDN, Queue Service for messaging, Table Storage. Essentially Microsoft are matching most of Amazon’s services, so I’d expect to see more tools arriving soon.
As we work with Azure I’ll post updates on how we’re getting on
Useful links
Convivial Coding 