Azure – first impressions

I signed up to a Windows Azure account earlier this week as i’m working on a project that I need hosting for, details of which will follow in due course. I had a look at a few hosting providers including (EC2 and Rackspace) and seeing as Azure is free throughout January and at 50% discount for 6 months, I thought I would give it a go.

Here’s my first  impressions:

1. Signup
   The signup process was far too long and overly complicated and on top of that the setup process just wouldn’t work for me in Google Chrome.
2. Setup
   The principles behind Azure are quite new – unlike EC2 there is no actual Windows Server OS running on a VM that you can just access via Remote Desktop, you need to set up the VM via a UI.
   You first have to set up a project, which is really the notion of the server itself. The project can then have multiple services running on it. The available services are Windows Azure (compute & storage) , Sql Azure (data) and AppFabric (service bus). The services can then have different roles which are the actual applications, for example the compute service can have a web role which is a web application or a worker role which is a windows service.
   For someone who’s used to administering a server and using the managment tools to set up websites etc this seems a bit like the basic version of a settings panel. I understand the reasons behind it, making it accessible for those not used to server administration, but I feel like I’m being treated like someone that shouldn’t be allowed to touch the advanced settings.
   

   Setting up Windows Azure services

3. Deployment
   The deployment process is actually very simple, although there  are a few annoyances.
   Building a Cloud Service in Visual Studio creates two files, the application package (.cspkg) and a configuration file (.cscfg) which need to be uploaded through the relatively clean Azure web interface. Strangely the Beta of Visual Studio 2010 creates the package files if you right click the Cloud Service project and click publish, but not if you click publish on the Build menu.
   Once you have your packages, you can deploy the service to a staging server first without any additional setup. A url is provided for the test server so you can do some testing and then once you are happy with it you can deploy it over to the production environment with one click.  Once deployed the service can be started, stopped, configured and deleted from the UI.

   

   At work we have a Continuous Integration environment set up with Teamcity running as our buildserver and automated deployments to our webservers, as nice as the Azure UI is, it would be good if the deployment is scriptable so it could be run automatically. I’m hoping at the very least that this becomes, if it isn’t already, part of  Visual Studio and TFS.

   The deployment process was really really slow and my deployment failed numerous times without any feedback as to why which made it impossible to debug. I still no idea why it wouldn’t deploy – I just recreated the Cloud Service from scratch and it worked.

I see this as ideal for a web developer who’s got no idea about server administration. I’ll persevere with it for now or at least until the end of the free period (end of January) but my patience is already starting to wain and the idea of EC2 is certainly quite appealing, despite the price differential.