Bruno Silva

After the yesterday’s announcement of Windows Azure, the brand new cloud-based Windows, today I started reading a little bit about it. This new platform seems promising, and I’ll write a bit about it in some of my next blog entries.

First of all I’ll talk about the Windows Azure, which is a part of the Azure Services Platform. It allows you to run applications and store data on the cloud (replace cloud by “a bunch o Microsoft data centers”). You can reduce the Total Cost of Ownership (I don’t say eliminate, because you will have to pay for the service), because you don’t have to build/buy/care about the infrastructure. You contract a service that is payed based on usage, so you can get scalable solutions even for start-up projects for which is difficult to predict the needs.

Computing

You can have 2 kind of applications running on Windows Azure. Web applications and workers (asp.net applications vs. something like the Windows services).

Web Role

Web applications are just like any web app that you write nowadays (receiving HTTP requests and responding) but in order to take advantage of the farm of virtual servers that Windows Azure provides you, your web applications should be stateless.

Well, not really stateless, but the state must be stored in a particular way. If you used session variables stored in the web server, you app would be attached to a particular server (the one to which the first request was made), this way any load balancing decision that lead your end-user to another server would lead to loss of that session data in the subsequent request… The right way to do it is to use cookies or (to prevent overhead on communications, or for security concerns) Windows Azure storage, which is available from all the virtual servers that serve your application.

Worker Role

Another option is to have an application that does some background work. They can’t have inbound communication, but can connect the outside world. They can read data from the Windows Azure Storage, and in the typical scenario, they get data from queues (which is one of the 3 storage mechanism of Azure). This kind of application can run indefinitely just like a Windows Service.

Storage

What about storage? There are 3 kind of storage that I’ll briefly refer.

Blobs - to store large amounts of unstructured data such as images, movies, binary data, etc. You can associate meta-data to blobs such as location and tags for a photograph or title of an audio file, etc. Whatever you need.

Tables - not regular relational tables, just a hierarchical set of entities and properties. You can access it’s data using LINQ and not SQL (to reinforce that this isn’t an SQL table :P)

Queues - As I wrote before the main purpose of queues is communication to and between applications instances with the worker role

All the storage is replicated 3 times in order to tolerate faults (at least some of them).

As far as I read, I wasn’t able to try it yet, the Windows Azure SDK allows you to develop your applications locally and getting some guaranties that when you deploy it into to the cloud it will work smoothly. Locally you can debug you application, which you won’t be able to in the cloud.

Next: .NET Services, SQL Services and Live Services