Five Steps Closer to Five Nines with WCF & Windows Azure

Delivering applications and services that are highly available is expensive. While WCF makes it possible to develop applications that can be deployed in a flexible manner to achieve various levels of availability and scale, it can be difficult to predict (and budget for) the appropriate level of availability given the not-so-predictable needs of the business and consumers. Windows Azure makes it possible to deploy WCF applications and services that theoretically can deliver unlimited levels of availability and scalability and be adjusted to the dynamic needs of an application’s user population. In this article, I'll explore how easy it is to develop, configure and deploy a .NET 3.5 Windows Communication Foundation service application for the Microsoft Windows Azure operating system.

Understanding Windows Azure from 10,000 Feet

Estimating and provisioning infrastructure is expensive because it is difficult to predict the elastic needs of an application over time. Even when engaging experts to conduct capacity planning, the needs of the business can expand and contract abruptly as demands for products and service are often elastic. The result is that often times, companies are faced with the choice to either go small or go big on their infrastructure purchases. The former introduces the very real risk of service delivery failure, and the latter can be prohibitively expensive. Many companies typically land somewhere in the middle, which means a never ending procurement process and ballooning expenses with server after server seemingly disappearing into a black hole. This is not only a drain on operating budgets from a hardware perspective, but in addition, provisioning and deploying servers is time consuming and expensive and detracts from the ability to deploy resources to more tangible revenue generating activities. Not to mention the cost of maintaining this ever-growing number of machines grows exponentially with each new machine.

Imagine if you could architect, design and develop applications using the .NET skills you already have today and deliver your application to users at Internet-scale with just a few clicks. Rather than calculating the specific number of Web, application and database servers required to meet your customer’s needs today, tomorrow and during peak times (and hoping that you are not wrong); what if you could defer these decisions to the appropriate time, and yet guarantee scalability, reliability, performance and reliable failover?

In addition, what if you could provide your customers with a pay-as-you-go model in which they only pay for what they use, whether they are a small start up just getting started or an existing company launching a marketing campaign during the Super Bowl?

Now, imagine all of these benefits without ever having to worry about keeping up with security updates, patching servers, running backups or testing your failover or disaster recovery strategy.

Windows Azure is a cloud services operating system that is the bedrock of Microsoft’s Azure Services Platform and provides all of these capabilities and much more.

In addition to providing an operating system for the cloud, the Azure Services Platform includes .NET Services, SQL Services and Live Services technologies that enrich the development experience and reach of applications deployed in Windows Azure, in the enterprise, or a combination of the two.

In this article, I will focus on the Windows Azure cloud operating system which provides a development, run-time, and management environment that supports the ability to develop, deploy and run your applications at Internet-scale.

Windows Azure is comprised of two main services, a controller, and of course, a configuration system. I will cover each of these components next.

Note: Windows Azure is currently a technical preview technology. As such, much of what I present here is based on very early documentation and what I’ve learned on my own by using the technology preview. Don’t take anything I say here as the final word. As this goes to print, there may very well be new and improved ways of working with Windows Azure that I simply haven’t yet discovered.

The Compute Service

The Compute Service is a logical container for any number of Windows Server 2008 x64 virtual machines that host your application. The Compute Service is fronted by load balancers which ensure that requests for your application are always routed to an available virtual machine instance provided multiple instances have been configured.

The Compute Service is partitioned into two roles: Web Role and Worker Role. Each role has affinity to a virtual machine; however, an application in each role is never aware of what physical machine or logical virtual machine it is running on. This is key to how Azure scales and is yet another example of ever increasing levels of indirection required to solve the new challenges that modern computing introduces in new problem domains.

When designing an application for Windows Azure, your application must target either the Web Role, Worker Role or both. The distinction between the two is that an application designed for the Web Role runs IIS 7 and can accept HTTP/HTTPS requests from outside of the cloud (i.e., your desktop or your customer’s server in their own data center). A Worker Role can only accept input from another application inside of Windows Azure and accepts requests via Queue Storage. This really equates to the same way you might think about an application server in a traditional data center which may run a series of WCF, WF, BizTalk or Windows NT Services to do asynchronous heavy lifting in the middle tier.

Of course, you may chose to design your logical application taking a layered approach which includes both roles and this is an excellent pattern if you want to support background asynchronous work that does not consume resources in the Web Role application. In this article, I will focus on synchronous operations solely provided by the Web Role.

The Storage Service

The Storage Service provides three key storage options: Table Storage, Blob Storage and Queue Storage. Table Storage allows developers to model their conceptual schema using .NET entities without regard to the underlying logical storage technology. The Table Storage service is exposed using REST via an HTTP/HTTPS endpoint which provides the ability to insert, update, delete and read records within tables deployed to Table Storage.

Blob Storage allows you to store data in binary form, such as images, files or trees, and Queue Storage provides queue-based messaging between applications and roles.

In this article I’ll focus on Table Storage. As you will see later, if you are familiar with the Entity Framework, Table Storage should feel very familiar to you.

Azure Table Storage

As with all storage features in Azure Storage, Table Storage is an extremely scalable and reliable mechanism for storing the state of your applications and services. I won’t go into too much detail (for more information on Table Storage architecture see the sidebar “Azure Services Platform Whitepapers”) about Table Storage, but for now it will be helpful to think about Table Storage in a hierarchical form consisting of an account, tables, entities and properties.

When Microsoft provisions Table Storage, it assigns you an account. This account is the root of the hierarchy and consists of tables. Note that Table Storage has nothing to do with SQL Server. It is based on a different, highly replicated non-relational storage technology. With that clarification out of the way, a table composes one or more entities. An entity is analogous to a row in RDBMS terms, and each entity consists of properties. A property holds a value of a given value type and is analogous to a column. Remember, however, that Azure Table Storage is very different from RDBMs like SQL Server, so thinking of entities as property bags of key/value pairs instead of holding on to old metaphors is more accurate.

Some of the supported data types include:

• Binary (a byte array)
• Bool
• DateTime (a UTC timestamp)
• Double (64-bit floating point value)
• GUID
• Int (32-bit integer)
• Int64 (64-bit integer)
• String (which uses the UTC-16 encoding)

The Binary and String data types have an upper limit of 64 KB. This is for scalability and performance reasons (remember, normalization doesn’t really apply here).

Tables are partitioned to aid in scalability and performance. I’ll cover partitions in more detail later, but the idea is that you want to keep similar data physically together and thinking about partitioning ensures that your queries and transactions run as efficiently as possible given the manner in which the entities may be distributed to meet scalability and reliability goals that are central features in Table Storage.

Development Storage

For simulating the Compute Service, the Windows Azure SDK includes a Storage Service emulator intended for local development and testing called Development Storage. Development Storage provides a development experience that is very close to working with Azure Table Storage at the API level. As you will learn, the provisioning of storage and tables is different in Development Storage and Azure Storage.

The Fabric Controller

As I mentioned earlier, the affinity between applications and roles is an important part of the scalability story, and the Fabric Controller provides a nexus that binds the virtual machines in a data center together and addresses cross-cutting concerns such as monitoring and logging via role-specific agents that run on each virtual machine.

The Fabric Controller manages the creation and disposal of Virtual Machines which are Windows Server 2008 x64 machines running on Windows Hypervisor technology. Based on configured settings, the Fabric Controller will spin up new VMs as needed. In addition, the Fabric Controller is responsible for monitoring switches and load balancers in addition to the physical and virtual machines. When allocating VMs, it does so intelligently. For example, if a Web Role application is configured for four instances, it will allocate and deploy the VMs such that a hardware failure, say of one load balancer, doesn’t bring the entire application down.

An important component that provides the Fabric with real-time monitoring information is the Azure Agent, which is deployed on each VM. The agent provides the Fabric Controller with health and status information so that it is always aware of the status of the physical and logical components under its control.

As of today, it is reported within authoritative sources (see the “Azure Services Platform Whitepapers” sidebar) that each virtual machine is isomorphic to a processor core, which is pretty impressive. This is where you start to really appreciate the scale we are talking about here. For example, there is a video on You Tube (see sidebar “Massive Scale”) of a reporter doing an on-site interview at one of the many Microsoft Azure data centers literally scattered around the world. This facility alone has 10 server rooms, each with a capacity to hold 30,000 physical servers. Doing some quick math suggests that if each physical machine contains 4 cores (which is probably conservative) an Azure data center can host 1,200,000 Virtual Machines. That is one million, two-hundred thousand VMs folks.

I have it on good accord that if a component in a server fails, be it memory, a disk in a raid array or a network card, the machine is put into a failed state, replaced immediately by a standby machine and the faulted machine is pulled from the rack.

If you are starting to appreciate the true scale of Windows Azure, you are not alone. As with most new technologies I get involved with, what usually gets me interested is that “oh wow” moment. If you are having such a moment and want to learn more about how these data centers work, take a look at the sidebar “Generation 4 Modular Data Centers.” It is truly fascinating.

The Local Development Fabric

As with Development Storage, the Windows Azure SDK includes a local development emulator called the “Development Fabric” which allows you to build, deploy and test your applications for Windows Azure in your local development environment. You might think of the Development Fabric as the Azure equivalent of Cassini, which provides an Azure hosting and debugging experience, only instead of mimicking IIS, it emulates Azure.

By: Rick Garibay

With over 13 years’ experience delivering solutions on the Microsoft platform across industry sectors such as finance, transportation, hospitality and gaming, Rick is a developer, architect, speaker and author on distributed technologies and is the General Manager of the Connected Systems Development Practice at Neudesic.

Rick specializes in distributed technologies such as Microsoft .NET, Windows Communication Foundation, Workflow Foundation, and Windows Azure to deliver business value and drive revenue while reducing operational costs.

Rick serves as a member of the Microsoft Application Platform Partner Advisory Council and is an advisor to Microsoft in a number of capacities including long-time membership on the Business Platform and Azure Technology Advisors group. As a five-time Microsoft Connected Systems MVP, Rick is an active speaker, writer and passionate community advocate in the national .NET community. Rick is the Co-Founder of the Phoenix Connected Systems User Group, celebrating four years in operation.

Recent presentations include talks at the Microsoft SOA and Business Process Conference in Redmond, WA, Microsoft TechEd, DevConnections, .NET Rocks, Desert Code Camp, and numerous Microsoft events throughout North America. Rick is a frequent contributor to industry publications such as CODE Magazine, and is the co-author of Windows Server AppFabric Cookbook by Packt Press.

When not immersed in the work he loves, Rick enjoys mountain biking and spending time with his wife, Christie and two children, Sarah and Ricky.