Microsoft Azure: Enterprise Application Development: Straight talking advice on how to design and build enterprise applications for the cloud

We aren't all graced by management with a strong technical background, and yet they need a deeper dive into the shallow end to achieve a win-win situation and obtain senior management buy-in to leverage this new platform. Sometimes, it's like you actually do work in the same office as Dilbert.

As we mentioned before, Microsoft Azure actually refers to a menu of services offered by Microsoft; each of these services is contained in the Azure Fabric. The Azure Fabric is essentially every piece of hardware and the software that monitors and controls the hardware. Every server, every firewall, every load balancer, failover services in the event of a failure, the Azure portal where we provision and deploy our application, create and check the health of our current services–they're all part of the Azure Fabric. Fabric in this case has a very large definition–as far as the Azure universe is concerned, the Azure Fabric is the continuum of space and time.

The three...

The service offering that has commonly been referred to as Azure is actually Windows Azure. For the rest of this book, when we refer to Azure, we'll call it Windows Azure.

Windows Azure is just what it sounds like–it is the operating system part of the cloud, with a few other features. The most inflexible part of the Azure universe is the fact that Windows Azure is not designed to provide customized virtual machines; (custom VHDs are a newly announced offering at PDC10, but are a different service than Windows Azure) we are limited to a 64-bit version of Windows Server 2008. We can create VMs of different sizes (the sizes relate to costs), and the OS is highly configurable, but it must remain Windows.

Windows Azure encompasses two areas of functionality–the compute service and the storage service. The next diagram shows how these services fit into the Azure universe. Additionally, there is an Azure Fabric Agent that connects the VM to the rest of the cloud. The Fabric Controller...

Originally known as SQL Data Services, SQL Azure for many people is the most exciting item on the Microsoft Azure menu.

SQL Azure is an almost feature complete implementation of SQL Server 2008 Geographic data types are now supported. Unlike Table Storage, SQL Azure is completely relational, with a defined schema, supports T-SQL, and we can connect via ADO.NET or ODBC.

We can manage our SQL Azure databases through the SQL Azure Portal, directly via sqlcmd, or through SQL Server Management Studio 2008 R2. At the time of writing, SQL Server 2008 R2 is the most recent release of SQL Server, and is the only SQL Server Management Studio (SSMS) version that can completely connect to SQL Azure. Microsoft provides a SQL Azure Database Manager (formerly known as Project Houston), an online tool that is used to manage SQL Azure databases. There are also a couple of third-party tools, such as SQL Azure Manager and the Omega Web Client, for managing SQL Azure. Undoubtedly, more tools will...

AppFabric is another part of Azure with "fabric" in its name. AppFabric was originally known as BizTalk Services, and then later as .NET Services. Unlike the Azure Fabric or the Azure Fabric Agent, AppFabric is not a low-level controller/manager of the virtual machines. Instead, AppFabric provides the Service Bus, Access Control services, and connection components.

The Service Bus is the functionality that serves as a bridge between on-premises applications and Windows Azure. The Service Bus also facilitates bidirectional communication between two non-Azure applications.

Bridging local and Azure applications is useful in certain cases such as if there is information in our local warehouse management system (WMS) we want to make visible to our clients via an Azure-based portal we develop. If our WMS has an API we'd like to manifest directly to our partners, we can also use the Service Bus to abstract the WMS API. In this case, we'd register our WMS's endpoint...

Project Dallas is Microsoft's entry into the new data-as-a-service (DaaS) market. The goal of Dallas is to provide a single authoritative source and a single billing method for public data. Think of Dallas as a "data marketplace", where we can buy subscriptions to data useful for our applications, and where data providers can sell their data.

The data in Dallas are accessible via a REST API, and can be consumed by applications on any platform. Support will be for SQL Server and SQL Azure to directly consume Dallas data, but this has not been delivered at the time of writing.

More information on Codename Dallas can be found at http://www.microsoft.com/windowsazure/dallas/.

The Development Fabric is yet another part of Azure with "fabric" in its name. The Development Fabric is a specialized Windows Azure environment used for local development. It is akin to the Azure Fabric, but is hosted on a single local machine. We install the Development Fabric with the Windows Azure SDK and other tools. We'll use the Development Fabric as we create our sample application through the rest of this book.

It's easy to think developing a web role is just the same as developing a traditional website, but that's not the case. The web role is not just a website, but a complete ASP.NET web application. If we have multiple instances of our web role application running, the Azure load balancer doesn't guarantee a user's connections will all be made on the same VM. One consequence of this is that our application should either be stateless, or use the database (or table/blob) or cookies to maintain session state. In-process session state isn't an option.

Imagine a local web farm with a load balancer that does not maintain session state. The ideal solution in this case would be to use some type of session storage to maintain state across servers. This is also the case with Windows Azure web role instances. We cannot maintain state in-process if we bounce between machines; however, the state can be shared using our table/blob storage or our SQL Azure service...

Microsoft Azure has two methods for calculating the monthly service charges – consumption pricing or commitment (subscription) pricing. Because Windows Azure, SQL Azure, and AppFabric are three independent services, each is priced separately and with its own rates. The charges may seem like nickel-and-diming as they are broken out by the different features of each service, but having the charges broken out allows us to utilize and pay for only what we use.

In addition to production-scale pricing plans, Microsoft also offers limited-use plans suitable for development and conference room pilot efforts. For the most current rates and offers, visit http://www.microsoft.com/windowsazure/pricing/. We're not going to list the base rates here, as they are likely to change over time. Instead, we'll look at how the charges are applied to each service in the next section.

Cloud services such as Amazon EC2 bill in a manner close to what Microsoft does, yet offer a little...

In this chapter, we had a quick look at the features of Microsoft Azure and how to calculate the costs of the Microsoft Azure platform. From Windows Azure, to SQL Azure, to Dallas, Microsoft has a complete and useful cloud offering. We'll spend the rest of this book examining most of these features of Windows Azure, SQL Azure, and AppFabric in greater depth, and building a sample application using these features.