« October 2009 | Main | December 2009 »

November 2009

November 18, 2009

Using Custom Domains with Windows Azure Services

A colleague of mine from the previous group asked me whether Windows Azure Hosted Service and Storage Account can share the same domain. Currently if you deploy Hosted Service on Windows Azure it will be accessible through an URL with the following format:

http://[servicename].cloudapp.net

 

At the same time if you create Windows Azure Storage Account, the containers and blobs will be accessible through an URL like this:

http://[accountname].blob.core.windows.net

 

If you are Web Developer, and plan to develop application for Windows Azure it will be important to have the same domain for both. There are many reasons for that, among which are branding, SEO, Ajax security and so on. Here is how you can achieve this.

Using Custom Domain with Windows Azure Hosted Service

For my test purposes I deployed the Hello World app that comes with the Windows Azure SDK samples. The URL of my Hello World Web app provided by Windows Azure was:

http://toddysm.cloudapp.net

 

After that I went to my registrar’s Web site and created CNAME that points to the above URL:

http://azureapps.toddysm.com –> http://toddysm.cloudapp.net

 

Once the CNAME was registered I verified that I am able to access my Hello World using the new URL. Voila!

image

 

Using Custom Domain with Windows Azure Storage

Now that I have my Hosted Service accessible through my custom domain, I had to configure my Storage Account to use custom domain too. Steve Marx describes the process in details in his post Using the New Windows Azure CDN with a Custom Domain. I skipped the CDN part but went through the remaining steps for configuring custom domain. Unlike the configuration for the Hosted Service, the Storage Account requires verification by Windows Azure. Hence you need to go through a couple of more steps.

The endpoint URL for my storage account provided by Windows Azure was:

http://toddysm2.blob.core.windows.net

 

You can find this information on Windows Azure Developer Portal when you click on your storage account. At the bottom of the page is also the section for configuring custom domain:

image

 

Clicking on Manage forwards you to the configuration page:

image

You need to type your custom domain and generate a key, which you use to create a CNAME that points to:

domainverification.windows.azure.com

 

image

You create the CNAME with the special key on your registrar’s Web site. Once the CNAME is created you click on the Validate button at the bottom of the page. If you registrar takes too long to create the CNAME you can return to the Storage Account summary page and you will find link to validate the domain in the section Custom Domains:

image

Once you have your domain validated you can create the actual CNAME at your registrar’s web site. In my case this was:

http://azurestorage.toddysm.com-> http://toddysm2.blob.core.windows.net

 

And, of course you need to test whether everything works as expected. For my test purposes I uploaded sample HTML file into my storage account and allowed public access to the container.

image

 

Now both, my Hosted Service as well as my Storage Account use the same top level domain.


Advertisement


   

November 16, 2009

Windows Azure Terminology in Simple Words

Every time I start working on new technology I get amazed how many new terms we can invent as humans. From one side this is good because it demonstrates how easily we can make progress, but from other it can be an obstacle for somebody who wants to get onboard fast. In this post I will try to explain some of the Windows Azure terminology the way I understand it.

Windows Azure Services

Without going into details about the internals of Windows Azure I need to say that there are two main services that every developer needs to be aware of: Compute and Storage.

Compute is the computational part of Windows Azure, and very often it is referred to as Hosted Service. Windows Azure Fabric is the component that manages the Hosted Services - David has a very nice post explaining how this works in the datacenter (see David L's Blog - Windows Azure - What Happens in the Data Center?). Fabric takes care of the deployment of your service, restarting it if something goes wrong, managing the resources available to it etc. From now on I will refer to the computational part of Windows Azure as the Hosted Service.

Windows Azure Storage is the second service available for developers. It is also referred to as Storage Account. Storage consists of three main parts:

  • Blob Service (or just Blob) – used to store and retrieve large amounts of binary or text data
  • Queuing Service (or just Queue) – used to store and retrieve messages
  • Table Service (or just Table) – used to store structured data (however you should not confuse it with SQL Azure)

As of last week Storage provides nice features like CDN and Custom Domain association. From now on I will refer to the Storage Service as Storage Account or just Storage.

Both Fabric and Storage are simulated in the development environment available as part of the Windows Azure SDK (also called Development Fabric and Development Storage).

Looking at Compute (i.e. Fabric) and Storage as components of Windows Azure is just one way to abstract the system and by no mean the only way or the way Windows Azure team does it. This is just a simplification I decided to use to make my life easier when I look at Windows Azure from developer point of view.

More about Hosted Services

The Hosted Service is the actual application you deploy on Windows Azure. Every Hosted Service in Windows Azure can have Web Role and Worker Role.

The Web Role is intended to provide the front end for communication outside Windows Azure, while the Worker Role’s is intended for background processing.

It is very important to understand that there are certain limits of the number of roles in a Hosted Service. The CTP (Community Technology Preview) program allows developers to have up to 5 roles in a Hosted Service; only one Hosted Service and two Storage Accounts are allowed for CTP users. Currently every Hosted Service is deployed on a separate VM (Virtual Machine).

As a developer you can mix and match the types of the roles as you want as long as you don’t exceed the limits. Going forward those limits will change in accordance to the subscription program Windows Azure team will introduce.

VIP-Swap and In-Place Upgrade

One very important term is the VIP (Virtual IP) address – this is the publicly accessible IP address used to access your Hosted Service; or this is the IP address of the Load Balancer in front of your service. Windows Azure provides the concept of VIP-Swap where you have two services with their own VIPs (and corresponding domain name), and you can swap those so that the first service uses the VIP of the second one, and the second service uses the VIP of the first one.

This is quite useful if you want to have no downtime update for your application. You can use the Staging Environment of your Hosted Service to deploy your new bits, and test those, and once you are ready you can swap it with the Production Environment. You can keep the production bits for some time in case you need to roll back your changes.

Of course more advanced technique to do upgrades is the In-Place Upgrade Windows Azure offers (In-Place Upgrade is explained very well in the Windows Azure Documentation). In-Place Upgrade uses the concept of Upgrade Domains where instances of the roles are separated in two groups, and those groups are upgraded in a sequence. In-Place Upgrade provides also more flexibility and control from developer’s point of view.

 

Clarifying the terms above helped me get better understanding of the Windows Azure platform. Going forward I will try to explain every new term and clarify its meaning and intended use.

November 11, 2009

Getting Started with Windows Azure

With my recent move to Windows Azure I had to learn bunch of new things. As with everything else the hard part is to find out where to start from. Of course the usual start nowadays is the Web – you just type http://www.windowsazure.com and voila – you are there. If you are developer you can certainly skip the marketing messages and jump directly to the Developers section, however I would recommend to glance through Products one so at least you can get some idea what Windows Azure is and how the branding is done (I may write a bit more about the Windows Azure branding in another post).

 

Installing Windows Azure Tools and SDK

Now, getting back to the developers part. Clicking on the Get Tools & SDK button will send you to Microsoft Download Center – at this time the only available download is Windows Azure Tools for Microsoft Visual Studio July 2009 CTP (CTP stands for Customer Technology Preview). Next version will be released at PDC09. If you are like me you will click on the download button and select Run immediately. Don’t do that – the installer will stop and tell you that you miss some prerequisites! There are certain prerequisites that you need to install and configure before you will be able to install the Tools and the SDK. Scroll down the page and read those – here listed for convenience:

  • Visual Studio 2008 SP1 or 2010 Beta 1 (of course you need that)
  • SQL Server Express Edition (or above)
  • Enable IIS 7 with ASP.Net and WCF HTTP Activation
  • Install couple of other hotfixes

The one I had most trouble with was enabling IIS 7 with ASP.Net and WCF Activation. In general the issue I was hitting was the one described in the following post Enabling WCF HTTP Activation After Uninstalling Microsoft .Net Framework 4.0 Beta. Once I had this issue behind, the rest of the installation was matter of minutes.

Note: Windows Azure doesn’t support .Net Framework 4.0 yet.

 

Windows Azure Samples

Windows Azure SDK comes with a set of samples that can help you ramp up faster. Once you unpack the samples you can use the provided build scripts to build the samples. Because I was interested in the storage functionality initially the two samples I’ve build were CloudDrive and StorageClient.

Of course, in order to run the StorageClient I had to have the local storage running. Everything was fine, except that I couldn’t start the Table Service. Selecting the service and clicking on the Start button didn’t change the status of the service, and there was no error message either. The reason for that was the lack of schema configuration for the Table Service. If you are more familiar with the SDK you may be able to create your own schema and use DevtableGen.exe to generate the database. I discovered that the schema is missing after clicking on Tools –> Table service properties in Development Storage UI. I wasn’t familiar how to build my own schema, however after building CloudDrive project the sample schema was automatically generated and applied to Development Storage.

 

Now, I think I have my environment set up and I can get to my first project.