Welcome to the first of an ongoing blog series based on my latest PluralSight course, Applied Windows Azure.

“Applied Windows Azure” as the name suggests, is about utilizing various building blocks to develop practical, meaningful and cost-effective applications that run on Windows Azure.

This course is broken up into 10 modules (listed below). Within each module, after motivating the use of the relevant building Azure building blocks, I cover the core concepts, key mechanisms and design tradeoffs. Of course, no course can be complete without looking at some code – so  I’ll walk through important parts of an application built specifically for each module.  All source code is provided as part of this course.

Finally, the focus is on breadth learning — the ability to operate across the Windows Azure building blocks in a coherent and productive way.  My hope is that the viewer walks away from this course with an idea to apply these Windows Azure building blocks/patterns to a challenge specific to their own domain.  I encourage the viewers and readers to reach out to me at @vlele or comment below anytime to continue this discussion. The value of a course of this type is greatly enhanced by a two-way conversation.

List of Course Modules:

  • Readymade Execution Units with Azure Web Sites
  • Compute Intensive Apps with Azure Worker Roles
  • Identity & Access with Windows Azure Active Directory
  • HIPAA Compliant Apps with Windows Azure Trust Center
  • Loosely Coupled Apps with Azure Service Bus and Mongo DB
  • Offloading SharePoint Customization to Windows Azure
  • Mobile Services as a backend for any app (not just mobile apps)
  • Integration with Windows Azure BizTalk Services
  • “Big Compute” with Azure HPC Services for Excel
  • “Big Data” with Windows Azure HDInsight

I am going to assume some basic understanding of Windows Azure building blocks. If you are new to Azure, there is some excellent material on MSDN and Windows Azure Toolkit to get you started.

Here’s how each blog post for this series will be structured: For each scenario, we start out with the key motivation for the building block, followed by a discussion of scenarios where this building block may be applicable. Next, we will cover the core concepts in detail by walking through a diagram or some sort. Finally, we will look at some of the key design considerations and tradeoffs associated Azure Web Sites.

Motivation

I have to be honest, when Azure Web Sites came out I thought: Looks like a great tool for hosting my daughter’s soccer team site. For everything else I will continue to Web Roles.

And..boy, was I wrong! Over the last year, I’ve used Azure Web Sites for everything from hosting REST Endpoints, hosting SharePoint Apps, execute scheduled jobs and of course hosting web apps. And through this journey, I have come to see the Azure Web Sites as a readymade execution unit.

What do I mean by that? I mean it is a completely managed execution environment for any code (ASP.NET, PHP, Node.js, Python) that you may want run in the cloud in response to a http-based input. No need to worry about underlying hardware, software OS or the need to cluster instances to get the availability SLA (unlike a web role). You can also scale it up and down based on the load by sliding the slider or calling an API — scaling both vertically and horizontally, i.e. bigger compute execution environment or multiple compute execution units. And all of this with a deployment scheme that takes seconds (also unlike a web role). Finally, you can host multiple websites within a single instance of Azure Web Sites, allowing you to build your own micro-site hosting applications.

Scenarios

Based on the above discussion around scalability, fault tolerance and monitoring, it should come as a no surprise that large corporate web properties can be hosted on Azure Web Sites. Additionally, marketing agencies that need to deploy micro-sites (a micro site for each campaign, say) are good candidates for using Azure Web Sites as well. Since Azure Web Sites can host middle-tier logic based on technologies such as Web API, Azure Web Sites have a role to play in building multi-tier cloud based applications.

Core Concept

The following diagram depicts the core concept that powers Azure Web Sites. Azure Web Sites are sites that are dynamically provisioned when the very first request arrives (or if a site has gone dormant). Incoming requests arrive via the Azure Load Balancer (LB) and are routed to set of IIS / ARR servers. Think of the ARR servers as a reverse proxy and load balancing layer. An incoming request is then checked against a set runtime database to ensure that quotas are not exceeded. Assuming that is the case, the incoming request then directed to an instance of web role (amongst a pool of web roles maintained). This will result in a site being provisioned. Unlike a default IIS installation, which maintains the root of the configuration in ApplicationHost.config file, Azure Web Sites maintain this information in the runtime database that we discussed earlier (The motivation for this design choice is clear – we don’t want application roles to reset every time a new Azure Web Site is provisioned). Finally, the content is served, not from disks attached to Web role, but from an Azure Storage Blob location mounted as a disk (also referred to as Azure Drive). As you know, Azure Storage Blob offers high redundancy and throughput by maintaining three copies of data). Subsequent requests don’t have to go through steps two and four, as the site is already alive.

One other interesting feature to call out is the support for stateful sites. ARR allows cookie-based client session affinity (unlike the Azure LB, which purely based on a stateless round-robin load-balancing algorithm). This means that subsequent requests will be routed to the same Azure Web Site instance that originally serviced the incoming request. You may be wondering why we have only talked about a single instance thus far. But you will see later that Azure Web Sites can be scaled up by adding additional instances. This is when having stateful sites can come in handy.

Design Considerations

Here are some design considerations as you look into using Azure Web Sites

• Know the restrictions on code running within Azure Web Sites. For example, does the code need to run under an administrator account (registry or file system access)? If yes, you may need to use web role.
• Choose between different modes (free, shared and standard) and sizes of the website (small, medium and large) based on the expected load.
• Choose the appropriate instance count and decide whether it makes sense to scale the number of instance by schedule (certain time period in a day) or scale by metric ( CPU Utilization).

Summary

Azure Web Sites offer a powerful way to develop web applications, host REST endpoints and even serve up lots of micro-sites in a cost-effective manner. Azure Web Sites can be thought of as “ready-made execution units” that can be stamped out on demand. Think of each such “execution unit” to be a completely managed environment (no need to deal with underlying hardware, software, patches, fault tolerance or scalability setup) for hosting your code that can respond to an http-based request.