• <1 minute

Building Blocks of Great Cloud Applications

Editors note: this post was written by Michael Thomassy, Principal Program Manager, Windows Azure Customer Advisory Team Following the blog on Designing Great Cloud Applications, the Azure CAT team…

Editors note: this post was written by Michael Thomassy, Principal Program Manager, Windows Azure Customer Advisory Team

Following the blog on Designing Great Cloud Applications, the Azure CAT team is planning to give more detail and technical explanation to the components found in the code project Cloud Service Fundamentals in Windows Azure posted on MSDN Code Gallery. This starts the series of blogs and tech articles to describe the use of these fundamental build blocks which we’ll refer to as components.  Over the course of the next several months, we will be publishing a series of blogs every other Thursday with detailed technical notes that walk through the individual components of Cloud Service Fundamentals.

Over the years we’ve worked with Windows Azure customers, within and outside of Microsoft, with many deep discussions about what is needed in their Windows Azure services.  We’ve seen firsthand how answering some basic questions about implementing cloud services can grow quickly in complexity.  For example, rather than giving just a piece of sharding code, we need a data access layer.  Followed by resiliency of the data access layer that require developing retry logic as well as solid guidance for logging errors at scale.  Not to mention building an ops store you can query for reports and generate alerts.  You can see how the discussion progresses with each component as they depend and build on one another. These discussions and implementations resulted in the code project Cloud Service Fundamentals in Windows Azure that ties together a number of basic components into a working cloud application.

This code project was a challenge for the CAT team as we were focused on enabling complex, database backed services on Windows Azure for some of our largest customers.  It’s based on work that we did with actual Windows Azure customers to solve specific problems.  These problems often required best practices beyond the basic samples when we combined many of the requirements of large scale cloud services including elastic scale, partitionable workloads, availability, business continuity, large number of distributed users, and high volume, low latency requests.  You can see the architecture for the Cloud Service Fundamentals code project below. 


Our technical series will detail the components in the code project, including:

  1. Telemetry – The basics for instrumentation and logging of application services through asynchronous mechanisms at scale implemented in a data pipeline.  Effectively leveraging the telemetry data is critical in troubleshooting a service and determining the health of a service.  The code project implements a scheduler using a background worker role to collect telemetry data periodically from the application, perf counters, IIS logs, event logs and the sharded SQL Database DMVs. The data is written to a custom ops store database in Windows Azure SQL Database.  The data collected by the scheduler can be viewed by reports hosted in SQL Reporting.
  2. Data Access Layer – The layer accessing the multiple databases in Windows Azure SQL Database efficiently and reliably.  The code project has data access wrappers for both single-database and sharded solutions, and demonstrates techniques such as parallel fan-out queries across shards.
  3. Caching – By using Azure Caching, user data may be stored and retrieved more efficiently from a dedicated cache when combined with the Data Access Layer.
  4. Configuration – Configuration files are key to help make managing your application seamless whether configuration parameters are in web.config or the service config – this should be transparent to the application.
  5. Application Request Routing – Implementation of cookie based routing & affinitization of users to multiple hosted services and sharded databases leveraging the ARR (Application Request Routing) technology in IIS to enable scale-out at the application service level with sharded databases.
  6. Deployment – Methods to deploy your custom configuration with multiple hosted services, variable number of instances and configuring the number of shards through the use of Windows Azure Cmdlets in PowerShell.

We’ll post technical blogs and publish the details on the TechNet Wiki.  Looking forward to your comments and contributions.