Amazon vs Azure

When Amazon’s EC2 service first came out I was amazed. I thought this was going to change things forever. When Azure first came out, I was a sceptic. The thing that put me off Azure was the tie-in. Microsoft to date are the only Azure hosting provider. I knew that there were Azure specific libraries, and that I would have to develop my app specifically for the Azure platform. Moving it elsewhere would be an expensive option. This assumption was wrong. In fact, I believe that most web-based applications could probably just be copied across onto Azure with modest, or even zero changes. It’s true, there are Azure libraries which provide you with access to things like performance counters, logging, Azure blob storage, etc… What I learned, is that most of this stuff is not necessary, and just ‘nice to have’. Playing with Azure helped me to appreciate what Amazon lacked.

With Azure your hands are tied, you upload your files, and you’re done (with the exception of pressing the ‘go live’ button). This means that Microsoft are responsible for deploying your solution across the server farm, but not only this, they take responsibility for patching the OS, for performing the ‘transitions’ (when you swap instances). With Amazon, you’re left to figure these things out for yourself. Of course, comparing the two technologies is like comparing apples with pears. Amazon allows you to do anything you want with just about any kind of machine image you could need, Azure hosts services, data and web roles, a narrow service offering, but this probably covers 90% of the use cases out there.

So anyway, here is a table to summarise the key differences between the offerings (there are plenty of similarities):

	Amazon EC2	Windows Azure
Deployment	You are responsible	Microsoft is responsible
Management (i.e. patching the OS)	You are responsible	Microsoft is responsible
Software licence cost (i.e. OS and database)	Free if using Linux/MySQL etc… otherwise you pay	Software licensing included in the cost
Choice	Runs whatever you want	Runs .NET services and applications that run on IIS (i.e. ASP.NET and PHP)

So my advice is; if your application will run on Azure, use it, otherwise it’s Amazon.

Advertisement

NHibernate Jet Driver

I wanted to connect Castle ActiveRecord to Microsoft Access (don’t ask me why), and struggled to find the required NHibernate Jet driver, in a compiled form. So I built the source against .NET 3.5, and you can download it here:

NHibernate.JetDriver.dll for .NET 2.0

NHibernate.JetDriver.dll for .NET 4.0

NHibernate.JetDriver.dll for .NET 4.5

REST in ASP.NET

SOAP based web services became too complicated (I completely agree), so Roy Fielding’s REST services emerged as the light-weight, quick and simple alternative. So I thought I would add some RESTful services to an ASP.NET project I’m working on. A quick scan around the internet revealed that this is no simple thing:

http://www.west-wind.com/weblog/posts/310747.aspx

http://msdn.microsoft.com/en-us/netframework/dd547388.aspx

Downloading a toolkit, setting up WCF Data and Service Contracts, messing about with web.config, blah blah, this is all too complicated, and is at complete odds with the REST principal of simplicity. So my solution? Create an ASP.NET page, remove everything on it, but a single repeater:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Rest.aspx.cs" Inherits="StateMagic.Web.Rest" %>
<?xml version="1.0"?><asp:Repeater runat="server" ID="repeater">
<HeaderTemplate><states>
</HeaderTemplate>
<ItemTemplate>  <state href="?state=<%#(Container.DataItem as string)%>&username=<%= Server.UrlEncode(this.Credentials.Username) %>&apikey=<%= this.Credentials.ApiKey %>&modelid=<%= this.ModelId%>"><%#(Container.DataItem as string)%></state>
</ItemTemplate>
<FooterTemplate></states>
</FooterTemplate>
</asp:Repeater>

Then in the code behind, you read in the parameters on the query string, perform the necessary database query, and bind the resulting objects to the repeater.

Yes, it’s ugly, but it’s simple, and you have ultimate control over the way the XML looks.

Perhaps it would be better to define an object model, and use the serializer to write that out to the response stream instead, but it seemed like more worker, and the serializer isn’t quick.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!