In a previous post I explained an overview of the storage options you have for Windows Azure. I’d like to pull back a bit today – because Windows Azure is often used as a single term, you might not be aware it actually is composed of three components. These components work together, but can also be used separately.
Windows Azure is a “Platform” – we hear that all the time. But what does that mean, really? It means you don’t have to install, manage, or care very much about the operating system and below. You write code, deploy it, and it runs. You can think of it like a Sandbox or Runtime. To do that, you have three main features you can code against.
The first is Windows Azure “Compute”. This is made up of two kinds of “Roles”. The first is a “Web Role”, which basically means ASP.NET. That’s just the delivery mechanism – within that you can write in languages like C#. The point is, a Web Role is the front end code, screens and so on that you expose to your users. The other Role is a “Worker Role”. This can use various languages as well, and is basically like the Windows Services or DLL’s you use today in typical .NET programming. Worker Roles are the programs that don’t have a front end to the user.
The second component (or feature) in Windows Azure is the Storage – which I explained in my earlier post. You have three types here – Blobs, which are like files, Tables, which are key-value-pair type storage, and Queues, which let Web Roles and Worker Roles communicate to each other.
The third component in Windows Azure is the Application Fabric. From a wide view, this component handles authentication (lots of options here) and transport – not only between Windows Azure applications, but even from servers in your four walls. In other words, you could take that large SQL Server or Oracle system and expose that to an Azure application, and you wouldn’t have to allow the users of the application into your network.
I’ll point back to this post from time to time as I explore each of these areas in more depth.