I finally got around to playing with the bits for the Azure SDK, which as of this writing is currently in May 2009 CTP mode. Here are some thoughts.

Pretty good local development experience

Develop against a local cloud, deploy to the real one. The “role” stuff related to the project types in Visual Studio is a little odd at first but once you get past it, it’s the normal Asp.Net development experience we’ve had for a long time now, at least until you want to use the Azure blob/queue/table-storage services.

Hosting services

Literally, File –> New Asp.Net Web Application –> Publish –> (Upload via Azure portal) –> done. Definitely was not expecting this to be so straight forward. Should be really easy to migrate existing Asp.Net sites to the cloud, providing they comply with Azure’s security posture.

There’s a real over-reliance on the StorageClient sample.

Every sample or piece of code for demonstrating developing against Azure is using the StorageClient library, which is one of the sample projects that ships with the Azure SDK. There are numerous posts out there saying it is not to be considered an official API, and that the REST APIs are the real deal. That’s fantastic, but I don’t think any developer is interesting in writing a bunch of HttpWebRequest-heavy code to use Azure or worse, build out their own end to end wrapper to the REST interfaces. Sure, if no official libraries are published, some usable ones will surely pop up on CodePlex but I don’t see how Microsoft would even consider not providing an official .Net API, given what it could potentially do related to adoption of their platform. Microsoft has historically been very pro-RAD in its development platform and tooling, and this is contrary to that, which is puzzling. I mean, one might half-expect to see a TableStorageDataSource control for WebForms. Instead, it sounds like there will be nothing but some docs on MSDN describing the REST calls.

Table Storage != table storage.

Table Storage has a strong connotation for “relational”, and Azure’s Table Storage is anything but. It really should be called Structured Blob Storage, because that’s basically what it is, storing a structured property bag instead of an unstructured blob of ones and zeros. Trying to develop a simple “Post has many Comments” example lead me down a path where I:

1. Chose Guids as object-keys. Since this is off-premises and not bound to a strict schema, there is no options for auto-incremented properties. You either handle it yourself at the application level or find a better way to handle uniqueness among your entities. Guid.NewGuid() to the rescue.
2. Realized I either don’t “get” Table Storage and/or I’m doing it wrong. The LINQ capabilities of table storage extend to 4 LINQ operators.  And of those, only the most basic ones. Better support for Take, combined with support for Skip and OrderBy/OrderByDescending would at least provide the foundation of something usable from a querying perspective. I get that it’s not relational, so joining and grouping are probably overkill, but not being able to get the second set of 50 posts sorted by publish date, without fetching all of them and doing it in-memory? Come on. Taking the effort to develop against table storage to leverage the scalability and availability does not make sense when you have to fetch a whole ton of entities only to do a bunch of manipulation in memory in order to send just the right ones back to the client/browser.

Because of the querying limitations, the only way I think I would use Table Storage in an Azure-centric application with non-trivial storage requirements would be to use it as a structured cache for highly-requested or relatively static data. The rest would come from or something else entirely, possibly Sql Azure, formerly Sql Data Services. Of course, Sql Azure isn’t available in any sort of CTP or preview, so the jury is out on that one.

Blob storage

This is the strongest part of the Azure platform as I see it today. Even with the over-reliance on the StorageClient sample, shoving files up to Azure to get reliable, scalable file hosting is one area I think will really shine.

No development support for Windows XP

This is kind of lame, in my opinion. But it will sting less when Windows 7 is out as I suspect a ton of people will be moving to that directly from XP.

Overall, I really do like the platform from a development standpoint. Looking forward to what comes out surrounding it during PDC later this year.