.Net web apps hosted in the Azure cloud


Update: 08 Oct 2012 I discovered that Azure will not allow usage caps, so I have discontinued my subscription in order to prevent excessive charges. I’ve left this post here for historical reasons. I may explore other hosting alternatives in the future

I’ve recently switched over two of my demo web apps I wrote some years ago into the Microsoft’s Azure cloud service, something that greatly simplifies deployment and reduces my web hosting costs.

The first is No longer active, see beginning of post My remote control demo application which was an exercise to show an example of the command pattern

More sophisticated is my blackjack game, No longer active, see beginning of post which in a previous post in I showed its design.

Given that I wrote these programs in 2009, I certainly would not implement them again in the same way, as I was using some old technologies that have since been superseded (web forms, Linq to Sql) and my code would this time around implement SOLID principles.

Having previously set up and deployed Ruby on Rails websites on the excellent Heroku platform, in comparison Azure requires much less initial set up. Azure being built into Visual Studios means the developer is shielded from the complexities of deployment.

Counting in Heroku’s favour is the deployment speed; simple Azure apps take at least seven minutes to deploy, compared to around 30 seconds for Heroku.

For example in Ruby On Rails once you have set up the rake file to deploy locally, you can make a few alterations to that file for production setting and then run it on the Heroku instance in exactly the same manner as deploying locally.
Azure invents a brand new deployment work flow for the local copy of the cloud, which feels alien.

However I’m somewhat comparing apples to oranges, but I thought I’d share my insights. As a platform I’ll now be using Azure over independent web hosting.

One minor gripe when migrating data from a non-azure database to an Azure database was being forced to create clustered indexes which were not necessary in the original database.

, ,

  1. No comments yet.
(will not be published)