Building Windows Azure Applications with the Caching Service

In this Article, learn how to use the Windows Azure Caching service for both your ASP.NET session state and to cache data from your data-tier. You will see how the Caching service provides your application with a cache that provides low latency and high throughput without having to configure, deploy, or manage the serviceOverview

The Windows Azure Caching service provides a distributed, in-memory cache for your applications. In this lab, you will learn how to use the Windows Azure Caching service for both your ASP.NET session state and to cache data from your data-tier. You will see how the Windows Azure Caching service provides your application with a cache that provides low latency and high throughput without having to configure, deploy, or manage the service.

Objectives

In this lab, you will learn how to:

  • Easily and quickly provision your cache through the portal
  • Use the caching service for your ASP.NET session state
  • Cache reference data from SQL Azure in the caching service
  • Create a reusable and extensible caching layer for your applications

During this lab, you will explore how to use these features in a simple ASP.NET MVC application.

Exercises

This lab includes the following exercises:

  1. Using the Windows Azure Caching for Session State
  2. Caching Data with Windows Azure Caching
  3. Creating a Reusable and Extensible Caching Layer

Connecting Apps with Windows Azure Connect

Windows Azure Connect’s primary scenario is enabling IP-level network connectivity between Azure services and external resources. The underlying connectivity model that supports this is quite flexible. For example, you can use Sydney to setup networking between arbitrary groups of machines that are distributed across the internet in a very controlled and secure manner.

Overview

To enable IP-level network connectivity between Azure services and external resources, Windows Azure Connect can be used. The underlying connectivity model that supports this is quite flexible. For example, you can use Windows Azure Connect to setup networking between arbitrary groups of machines that are distributed across the internet in a very controlled and secure manner.

The following diagram illustrates the key elements of the Windows Azure Connect model.

Windows Azure Connect creates a logical “virtual network” which can contain two types of entities: Azure Role groups and Machine groups.

  • Role groups map to Azure roles, which have been enabled for Windows Azure Connect. Only the Azure VM instances for a role are members of a role group – the admin cannot manually add or remove members. Windows Azure Connect automatically manages the membership of role groups – if you add or remove role instances, Windows Azure Connect will track this and update the role group membership appropriately.
  • Machine groups are admin-defined collections of external machines, which have been enabled for Windows Azure Connect through installation of the Windows Azure Connect Endpoint Software. An external machine can belong to at most one machine group.

Connectivity within the Windows Azure Connect virtual network is based on the following rules:

  • A role group can be “linked” to a machine group – this enables connectivity between the members of those groups. A role group can be linked to multiple machine groups – e.g. you could have an Azure web role that is connected to your “My Servers” and “My Laptops” machine groups as shown in the diagram above.
  • Members of a role group (the Azure VM instances) do not have connectivity with each other. In addition, a role group cannot be linked to another role group. These limitations are intentional – the Azure service model controls connectivity between roles and the Azure runtime supports connectivity between role instances. We did not want the Windows Azure Connect model to interfere with this behavior.
  • Machine groups can be linked, as mentioned above, to role groups. Machine groups can also be linked to other machine groups to enable connectivity between members of those groups.
  • Links are not transitive from a connectivity perspective. For example, suppose Group A is linked to Group B, and Group B is linked to Group C. Machines in Group A can communicate with those in Group B, and machines in Group B can communicate with those in Group C. However, machines in Group A cannot communicate with those in Group C.
  • A machine group has an “interconnected” property – if it is set to true, then all members of that group can communicate with each other. If it is set to false, then communication between the members is not allowed.
  • It is important to note that Windows Azure Connect does not affect or interfere with a machine’s existing network connectivity.

Objectives

In this lab, you will learn how to:

  • Provision a Windows Azure Connect service and associate it with your Azure subscription.
  • Setup network connectivity between Azure Roles and external machines.

Exercises

This lab includes the following exercise:

  1. Connecting an Azure Web Role to an External SQL Server Database with Windows Azure Connect
  2. Connecting an Azure Web Role to a on premise services with Windows Azure Connect

Windows Azure CDN

In this Article, you will learn how to scale your static blob content out to the Content Distribution Network (CDN) available in Windows Azure.

Overview

Windows Azure provides the Windows Azure Content Delivery Network (CDN) to deliver Windows Azure Blob content. Windows Azure CDN offers developers a global solution for delivering high-bandwidth content.

Windows Azure CDN has several locations globally (United States, Europe, Asia, Australia and South America) and continues to expand. Windows Azure CDN caches your Windows Azure blobs at strategically placed locations to provide maximum bandwidth for delivering your content to users. You can enable CDN delivery for any storage account via the Windows Azure Management Portal. The CDN provides edge delivery only to blobs that are in public blob containers, which are available for anonymous access.

The benefit of using a CDN is better performance and user experience for users who are farther from the source of the content stored in the Windows Azure blob storage.

When you enable CDN access for a storage account, the Management Portal provides you with a domain name of the following format: http:/ /<identifier>.vo.msecnd.net/. This domain name can then be used to access blobs in a public container. For example, given a public container “images” and a storage account “youraccount”, once the storage account is enabled for CDN access, users can access the blobs in that container using either of the following two URLs:

When a request is made using the Windows Azure Blob service URL, the blob is read directly from the Windows Azure Blob service. When a request is made using the Windows Azure CDN URL, the request is redirected to the CDN endpoint closest to the location from which the request was made to provide access to the blob. If the blob is not found at that endpoint, then it is retrieved from blob storage and cached at the endpoint, where a time-to-live (TTL) setting is maintained for the cached blob. The TTL specifies that the blob should be cached for that amount of time in the CDN until it is refreshed by the Blob service. The CDN attempts to refresh the blob from Windows Azure blob storage only once the TTL has elapsed. As described in this msdn article, the default TTL is calculated as 20% of the interval between the present time and the last-modified time, up to a maximum interval of 72 hours. For example, a blob whose last-modified time was 30 minutes ago will be considered fresh for six minutes in the CDN cache. If this value is specified for a blob, then the TTL period will be set to the value specified in Cache-Control HTTP header.

The value of caching blobs in the Windows Azure CDN is realized only when the content is delivered from the CDN edge cache, so content requested only once during the blob’s TTL period will not get performance improvements from edge caching. The blob content that benefits the most from caching are blobs accessed frequently during their cached TTL period.

Blobs already cached in the CDN will remain cached until the TTL for each blob expires. When the TTL expires, the Windows Azure CDN will check to see whether the CDN endpoint is still valid and the Windows Azure blob is still anonymously accessible. If it is not, then the blob will no longer be cached. This means that if you want to change the content of the blob and the blob is currently cached in the CDN, the new content will not be available via the CDN until the CDN refreshes its content when the cached content TTL expires.

When you enable the CDN the configuration created for this endpoint is not immediately available; it can take up to 60 minutes for the registration to propagate through the CDN network worldwide. Users who try immediately to use the CDN domain name will get a 400 error until the configuration is updated worldwide.

Objectives

In this lab, you will learn how to:

  • Enable Windows Azure CDN
  • Leverage Windows Azure CDN for static content
  • Use TTL headers to control CDN caching scenarios

Prerequisites

The following is required to complete this lab:

  • IIS 7 (with ASP.NET, WCF HTTP Activation)
  • Microsoft Visual Studio 2010
  • Microsoft .NET Framework 4.0
  • Windows Azure Tools for Microsoft Visual Studio 1.6

Exercises

This lab includes the following exercises:

  1. Using the CDN to Deliver Static Content
  2. Managing Cache Expiration and Resource Versioning
  3. Caching Content from Hosted Services

Note: When you first start Visual Studio, you must select one of the predefined settings collections. Every predefined collection is designed to match a particular development style and determines window layouts, editor behavior, IntelliSense code snippets, and dialog box options. The procedures in this lab describe the actions necessary to accomplish a given task in Visual Studio when using the General Development Settings collection. If you choose a different settings collection for your development environment, there may be differences in these procedures that you need to take into account.