Provisioning Windows Azure for Web Applications

In the planning phase, you must gather all the requirements of your application. The following checklist contains items that should be researched during the planning phase:

• How is your web application currently being hosted? For example self-hosted or with a hosting provider such as GoDaddy.com.
  
  
• What is the domain name your application is currently using, and which registrar did you obtain the domain name from? For example GoDaddy.com or NameCheap.com.
  
  
• Does your web application require Secure Socket Layer (SSL) communication? For example a web site that uses an HTTPS address.
  
  
• What technologies and resources does it rely on? For example a database, file storage, caching, or message queuing.
  
  
• Is this application a Software as a Service (SaaS) ISV application?
  
  
• Who is responsible for billing, administration, deployment, and development roles within your organization?
  
  
• What your current development, staging and production environment is, along with your QA process.
  
  
• What Windows Azure subscription offering best fits your needs:
  
  
  • Special offers for MSDN, MPN, and BizSpark members
    
    
  • Pay as you go
    
    
  • Monthly subscription
    
    
  • Free trial
    
    
  • Invoicing if you are a Value-added Reseller VAR, or you have an enterprise agreement
    
    
  • Linking / Migrating from a Azure subscription to a EA
    
    
  For more information on these and other offers, see Windows Azure Platform Offers.
  
  

This section assumes that you have reviewed the Windows Azure subscription offerings and are ready to create a subscription. It also assumes that you have an understanding of the responsibilities called out in the planning checklist. The following table contains terminology used in this section that is specific to Windows Azure subscriptions

Using the table above, and the responsibilities identified using the planning checklist, you should be able to assign the Account Owner, Service Administrator, and Co-Administrators for your subscription after obtaining a subscription through the Microsoft Online Services Customer Portal (MOCP).

Note
There is no method to control the granularity of administrative access to a subscription; co-administrators have almost exactly the same permissions as the Service Administrator.

Using a single subscription for multiple projects can be challenging from an organizational and billing perspective also. The Windows Azure management portal provides no method of viewing only the resources used by a single project, and there is no way to automatically break out billing on a per-project basis. While you can somewhat alleviate organizational issues by naming all services and resources associated with a project similarly (HRHostedSvc, HRDatabase, HRStorage, etc.) this does not help with billing.

Due to the above challenges with granularity of access, organization of resources, and project billing, you may wish to create multiple subscriptions and associate each subscription with a different project. Another reason to create multiple subscriptions is to separate the development and production environments. A development subscription can allow administrative access by developers while the production subscription only allows administrative access to operations personnel. Separate subscriptions provide greater clarity in billing, greater organizational clarity when managing resources, and greater control over who has administrative access to a project. However this approach can be more costly than using a single subscription for all of your projects. You should carefully consider your requirements against the cost of multiple subscriptions. You can use tools such as Windows Azure Pricing Calculator to gain a better understanding of costs.

Note
When creating subscriptions, it is recommended that you use friendly names that relate to projects or organizations within your company. This helps in identifying which subscription is associated with a project or organization.

This section assumes that you have an understanding of the technologies and resources required by your application. The following table contains links to services provided as part of the Windows Azure Platform that can be used to replace some or all of the technologies and resources your application relies on:

Hosted Service

Local Storage

Storage Service

SQL Azure Database

Caching Service

This section assumes that you have an understanding of where your application is currently hosted, the domain name currently used to host your application, and whether your application requires SSL certificates.

If your hosted service requires SSL to secure communications with clients, you must obtain an SSL certificate and then install it using the Windows Azure Portal. After this, you must configure your application service configuration and service definition files to reference the certificate. If you already have an SSL certificate, you may be able to continue using it with Windows Azure.

Windows Azure allows you to specify a prefix for a hosted service, which is added to the Windows Azure domain of cloudapp.net. For example, specifying a prefix of ‘mysite’ will result in a fully qualified domain name (FQDN) of mysite.cloudapp.net. While this is sufficient for testing purposes, you may want to specify a different domain name that is more recognizable to your customers, such as www.fabrikam.com. This can be accomplished by using a CNAME record to map the Windows Azure assigned name of your service to a custom domain name.

Microsoft does not provide a mechanism for allocating domain names beyond those provided automatically by Windows Azure (Ex. *.cloudapp.net.) If you desire a custom domain name such as fabrikam.com, you must work with a registrar (Ex. GoDaddy.com, NameCheap.com, etc.) to register a domain name. After registering a domain name, use the tools provided by your registrar to create a CNAME record to point to the Windows Azure assigned name of your hosted service.

Note
This document does not provide any specific guidance on the process of creating a CNAME record, as it differs by registrar. Please consult with your DNS registrar for information on creating a CNAME record.

Note
One specific limitation of using CNAME records is that you cannot map the root domain (ex. Fabrikam.com,) to the Windows Azure DNS name; you must instead map a subdomain such as www or mysite (ex. www.fabrikam.com, mysite.fabrikam.com.)

When obtaining a certificate, you must specify the domain name that the certificate will secure. This should be the same as the domain name you expect clients to enter when visiting your site. For example, if customers will access your site through www.fabrikam.com, then you should request a certificate for www.fabrikam.com. If you need to secure multiple sub-domains (for example www.fabrikam.com and mysite.fabrikam.com,) then you should consider purchasing a Unified Communications Certificate (UCC), which is sometimes referred to as a multiple domain certificate. This type of certificate can secure multiple domains and multiple host names using one certificate. If you obtain a non-UCC, then you will need one certificate per unique domain name.

If you have an existing SSL certificate for the domain name you wish to use with Windows Azure, and the domain name can be defined using a CNAME record, you can continue using this certificate.

For information on configuring SSL with Windows Azure, see How to Configure an SSL Certificate on an HTTPS Endpoint.

An important consideration when architecting your solution is what datacenter your application will be deployed to. Ideally you want to deploy your solution to a data center that is close to the end users in order to reduce latency.

To reduce the need to deploy across multiple datacenters when serving a global audience, Windows Azure provides the Content Delivery Network (CDN), which allows you to cache static resources such as images, audio, or web pages across 20+ nodes around the world. While this may not initially seem useful for applications that dynamically generate data or web pages for visitors, you should evaluate how dynamic your solution needs to be. For example, if you have a message board application that presents users with a list of new conversations, you may be able to use the CDN for this content by moving the logic to create the list of conversations to a worker role that creates a static list every few minutes. If the list is populated from information in a SQL Azure database, this would also have the effect of reducing connections to the database.

For more information on using the Content Delivery Network, see Delivering High-Bandwidth Content with the Windows Azure CDN.

To ensure that all services in your solution reside on the same datacenter, Windows Azure supports the concept of affinity groups. Affinity groups allow you to create an alias for the datacenter you want to use, and this alias can be used when setting up each service. For example, if you wanted to ensure that all of the services and data associated with the HR project are located in the North Central US datacenter, you could either select the North Central US datacenter for each Windows Azure service or deployment, or you can create an affinity group with a friendly name such as “HRDataCenter”.

For more information, see How to Create an Affinity Group.

Other Resources