Moving your application to the cloud might not be easy as it sounds. The typical sample we always see in documentation or demos about an ASP.NET application created from the Visual Studio template and deploy it in Azure as a package is definitely very far from reality. There are multiple factors that can affect the response time and availability of your applications in the cloud but you can not easily see until you embark on a real project. Application distribution and deployment is one of those factors, and the one we are going to discuss in this post.
Windows Azure uses the idea of regions to manage the physical distribution of your applications and data. A region in a nutshell represents a Microsoft data center where you can deploy your application or part of it. Nowadays, you can find multiple regions spread across the globe in places such as North America, Europe and Asia.
There is another abstraction layer on top of regions called "Affinity Groups", which simply tells the Fabric controller to do its best to ensure groups of related services are deployed in close proximity whenever possible to ensure optimization for inter-app communication. For example, in a typical web application with a database, you will want to deploy the web application as close as possible to the database server.
Finally, another important concept you need to understand in this deployment model is the idea of “hosted service”. A hosted service basically represents an unit of deployment associated to a public DNS in the cloud. You deploy your applications in a hosted service, which is also tied to a region or affinity group. What Azure gives you is a public address for reaching that hosted service in the cloud, which is “[you app name].cloudapp.net” for applications hosted in the production environment and an auto generated guid for applications hosted in the staging environment. You can also think in a hosted service as a load balancer that forwards requests from that public address to one of the instances or VMs associated to it.
Let’s discuss the aspects you need to consider for selecting the right regions for deploying your application.
- Network latency: reducing the network latency is very important as it will impact directly on the response time for your applications. You will want to have your users as close as possible physically from your applications and data. For example, if you have some potential users in the US and Europe, you will want to deploy two exact replicas from your application and data in the US and Europe data centers. As you might guess, this is not as easy as it sounds and there are a lot of challenges you need to address, how you can effectively redirect the users to the right region, or how you can synchronize your data across regions are typical questions or concerns you have to tackle first.
- Availability: you will want to have your applications available all the time. Many things can happen, but you need to understand that a region or data center might become offline and your application should be prepared to handle that scenario. Your applications and data should be replicated across multiple regions to not be affected when things like this occur.
Microsoft already offers a set of tools or technologies you can use to address these two aspects, so let’s discuss some of them in detail in the next paragraphs.
Windows Azure Traffic Manager
While this technology is still a CTP and not available for all public in general, it will provide several methods for distributing internet traffic among two or more hosted services in different Windows Azure datacenters. It is in essence a distributed DNS service that knows which Windows Azure Services are sitting behind the traffic manager URL and distributes requests based on different policies or modes you can configure. It will initially support three modes, “Failover”, “Performance” and “Round-Robin”.
In the “Failover” mode, all the traffic is redirected to a single hosted service, unless it fails. If the redirection fails because the hosted service is not longer available, it then directs the traffic to the hosted service configured as failover. For example, you can configure the South Central US region as a backup for the North Central US region and vice versa. If any of those regions go offline, the other one will take its place.
In the “Performance” mode, all traffic is mapped to the hosted service “closest” to the client requesting it. For example, this will direct users from the US to one of the US datacenters and European users will probably end up in one of the European datacenters.
Finally, in the “Round-robin” mode, the traffic is distributed in a round robin fashion across several hosted services configured in the policy.
As you can see, this tool only tackles the two aspects mentioned before from the point of view of traffic redirection. However, you also need to make sure the data is also consistently available in all the regions, and that’s something this tool won’t solve. For example, if the users are redirected from North US to Central US, you need to make sure the data they get access look the same.
Content Delivery Network (CDN)
You can imagine the Windows Azure Content Delivery Network as a huge http cache spread across the globe for content such as images, files, scripts, or static html to name a few. You can either configure CDN for a blob storage account or an http endpoint in your application (and endpoint with an url ending in “cdn”, for example xxx.cloudapp.net/cdn). All that content will be cached in the nodes that are part of the network using standard Http caching. The CDN will serve later the cached copy closest to the user requesting it, improving in this way the response time.
There are today more than 18 locations or nodes globally (United States, Europe, Asia, Australia and South America) and this number keeps growing.
SQL Azure Data Sync
While the Azure Table Service already provides some built-in support for crash recovery based on the idea of partitions that are replicated across different nodes (in different sub regions, for example North US and Central US), a SQL Azure database is not prepared for that scenario. If you also use something like the Traffic Manager to redirect users to the closest data center, you probably would want to have all the databases in the different regions in sync between them making all this process transparent to the user.
If you want to support that scenario, the SQL Azure Data Sync is the tool that will help you in this matter. In a nutshell, SQL Azure Data Sync is a cloud-based data synchronization service built on the Microsoft Sync Framework technologies. It provides bi-directional data synchronization and data management capabilities allowing data to be easily shared across SQL Azure databases within multiple data centers.
There are a few things you will have to configure in this tool
- The databases you want to keep in sync, and also the tables and columns in those databases
- The schedule or frequency for doing the synchronization.
- How you want to resolve any conflict that might occur during the synchronization.
As you can see, the combination of this tool with the traffic manager will help you to keep applications and data in sync between different region for the most common scenarios.
A hosted service in azure is typically assigned with two public addresses, one for the production environment with a DNS name ending in cloudapp.net such as [your name].cloudapp.net and an auto generated DNS name for the staging environment such as 4969aae4e18f4699aa88223e1e73ba8e.cloudapp.net. There are multiple reasons you might want to map your custom domain name to these public names in Azure, but these are the most common ones I can imagine,
- You don’t want to tie your websites to a single cloud hosting vendor such as Microsoft
- You host multiple websites in a single hosted service in azure, so a single address such as xxx.cloudapp.net does not make sense anymore. In that scenario, you need to use different port numbers for the websites or use host headers, which is the typical solution. For example, you might want to map [your name].com and [your other name].com to two different websites in the same hosted service (xxx.cloudapp.net).
- You want to map a single domain to multiple hosted services in azure in different regions, and use geographic DNS routing to balance traffic. For example, you might have xxx-us.cloudapp.net for a hosted service in the US and xxx-eu.cloudapp.net for another hosted service in Europe but a single domain [your name].com that automatically routes the traffic according to the source of the http requests.
In the two first cases, the use of CName records in a domain that you own will work for redirecting all the traffic from there to the hosted service in Azure. The last one might require an additional DNS service like the Traffic Manager in Azure or Route53 in Amazon.
It’s common nowadays for most websites to host two different versions of the same portal for mobile devices and regular browsers, which basically fits in the scenario I described as number #2. We can not use the default addressing schema in Azure anymore because the IIS instance running in hosted service wouldn’t know how to route the traffic to the right portal. However, this can be resolved with a combination of CName records at DNS level and host headers at IIS configuration level.
Configuring different host headers for the websites in IIS is easy to achieve with the use of multiples bindings and endpoints at configuration level.
<Site name="Mobile" physicalDirectory="..\xxx">
<Binding name="HttpIn" endpointName="HttpIn" hostHeader="m.xxx.com" />
<Binding name="HttpInStaging" endpointName="HttpIn" hostHeader="stagingm.xxx.com" />
<Site name="Portal" physicalDirectory="..\xxx">
<Binding name="HttpIn" endpointName="HttpIn" hostHeader="www.xxx.com" />
<Binding name="HttpInStaging" endpointName="HttpIn" hostHeader="staging.xxx.com" />
The snippet above illustrates how the Service Definition should look for supporting two different web sites for the mobile site and regular web site. An important thing to notice in the configuration is that I also included the host headers for staging, so you can test staging as well before making the switch to production. This means will require a different set of CName records for staging and production,
- The “www” and “m” records will point to the production website in azure, xxx.cloudapp.net
- The “staging” and “stagingm” records will point to the auto generated address for staging in azure
A CName record for the auto generated address in staging is not a good thing as it gets generated every time you create a new staging deployment. However, there is no other good way to fix in the meantime unless you actually do not include this definition for staging and you test everything local by pointing your windows host file to the IP address in staging (For instance, www.xxx.com [Staging IP Address] and m.xxx.com [Staging IP Address]).
The service definition can not be changed or updated once the deployment has been completed so make sure to get it right in the first place.