A Windows Azure application currently looks a lot like an ASP.Net application, although it has some restrictions and additional features. Azure supports Web roles and Worker roles; a Web role is like an ASP.Net site, while a Worker role is a background process, like a .Net-based service. Roles may be given multiple instances, with each instance in a virtual machine under the control of the Windows Azure Fabric; a load balancer makes the cloud of Web instances respond to a single HTTP URL.
Azure stores blobs, tables, and queues for Web and Worker roles in a replicated storage instance; these are addressable by a RESTful URI (uniform resource identifier). Azure blobs (binary large objects) are very loosely organized into containers and blocks and may have associated metadata. Azure tables are hierarchically organized entities with properties, which may be queried using LINQ syntax; they are emphatically not relational database tables. Queues are used for reliable communication between Web role instances and Worker role instances, typically to post work items for processing.
.Net Services include the .Net Access Control Service, which controls access to Web resources using security tokens; the .Net Service Bus, which is a discoverable registry of Web end points; and the .Net Workflow Service, which is a sequential workflow controller. SQL Services currently includes only one of the several planned components: SQL Data Services, which is basically a hierarchical store of authorities, containers, entities, and properties addressable using REST or SOAP and either a LINQ-like language or ADO.Net Data Services. SQL Data Services may be based on SQL Server, but it isn't used like SQL Server.
The Live Framework enables access to Live Services and also to Live Mesh synchronization, using the Live Operating Environment (see diagram). In the interest of brevity, I'll defer any further discussion of Live Services to a future article or blog posting.
Currently, Azure development is done on Windows Vista SP1 or Windows Server 2008, using the various Azure SDKs and tools plus Visual Studio 2008 SP1. Getting started is a multistep process: You need to apply for the preview, then download and install the prerequisites, SDKs, and tools. If you're accepted for the preview, you'll receive tokens via e-mail that you can redeem to create instances of the various services.
Once you've installed everything you need and started SQL Server and IIS, you can test out the Azure development environment by building and running applications supplied with the Azure SDK locally. If everything is working correctly, a local fabric is created along with local blob, table, and queue storage.