Snip/Shot by Toddy Mladenov

Windows Azure deployment – did you forget to pack your DLLs?

OK, back to the topic deployment stuck in Initializing, Busy, Stopping! One more thing you can do is to crack-open your package and look inside if you have all the necessary DLLs. Thanks to Jim who send me the note, and has a good post how to look inside the service package.

Deploying Package with Missing DLLs on Windows Azure

Using the steps he describes in his post I created simple project. The app does nothing but shows static text. For the purpose of this exercise I have initially set Copy Local attribute for the following DLL to false:

 

Microsoft.WindowsAzure.Diagnostics 
 

After clicking Publish on the project I got the following in the output windows:

 

C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets(0,0): warning : CloudServices44 : Forcing creation of unencrypted package.

This is the guarantee that I have the package unencrypted, and will be able to look inside. Note: Please keep in mind that you will not see this warning in Visual Studio 2010 Beta because a bug.

In order to look in the package I had to change the extension of the package file from CSPKG to ZIP.

 

The next thing I had to do is to extract the CSSX file for the Web Role, and change its extension to ZIP. Just for your information Web Roles and Worker Roles are packed in CSSX files and stored in the main folder of the package file. The name of the file is the same as the name of the role you give in Visual Studio (in my case this was SimpleWebRole) followed by underscore and GUID.

 

 

If my dependencies were packed in the CSPKG file I would expect to see them in the following folder:

 

<%Role_Root%>/approot/bin

 

Of course, because I have set the Copy Local attribute to False, the diagnostics DLL was not there.

 

 

Deploying the package works fine, however trying to run it puts it in an endless loop between Initializing-Busy-Stopping:

 

 

 

Great! I managed to hose my deployment completely

Adding the DLLs to the Package and Re-deploying

Now, let’s get back to Visual Studio and change the Copy Local attribute for Microsoft.WindowsAzure.Diagnostics to True. Using the same steps as above I verified that Microsoft.WindowsAzure.Diagnostics.DLL was added to my package.

 

Deploying the package and running it produces the desired result – after some time I can see my role in Ready state and can load the default page of my simple application.

 

Few More Tips

As Jim mentions in his blog post Windows Azure service packages come in two flavors – the single file version and the CSX folder structure under the Visual Studio project. If you build your project and look in the following folder:

 

<%Project_Root%>\bin\Debug\[Project Name].csx

or 

<%Project_Root%>\bin\Release\[Project Name].csx

You will find your roles and the corresponding approot\bin folder underneath. If all necessary DLLs are in this folder they will also be packed in the single file version package that is normally deployed. In my case this was:

 

<%Project_Root%>\bin\Debug\Crack-Open Demo.csx

Important: You need to make sure that each role contains the necessary DLLs in its own approot\bin subfolder. The reason for that is that each instance of each role is deployed on a separate VM, and if those are missing the role will be cycling. 

Here are the links to my other posts that will hopefully help you resolve your deployment issues:
Windows Azure Deployment Stuck in Initializing, Busy, Stopping – Why?

Using Windows Azure PowerShell Sample to Investigate Issues with Cycling Roles

Guidelines for Specifying Windows Azure OS

Few days ago Windows Azure announced version 1.1 of Windows Azure OS and judging by how fast the announcement of Operating System Versioning in Windows Azure picked up on Twitter month and a half ago, I think the interest in the feature will be quite high. In this post I would like to give you some more details on what to look for, when selecting Windows Azure OS version.

Why versioning Windows Azure OS in first place?

The reason Windows Azure gives you the option to specify the OS for your guest VM is quite simple – you should be able to test your application before the OS it is running on gets updated. Although the believe is that minor updates of the OS should not break applications (and this may be the case in majority of the cases) there is still the risk that something may not be working after the upgrade. This problem becomes more severe when major upgrades come into play – then you need to have this option for sure.

Of course there is also the other camp – what about bug fixes and security updates for the OS? It is a fair point that those are important too, but here is the question to ask: “Would you rather have application that doesn’t work and is secure or have application that works but is insecure?” There is no right answer for that. Or I would rather say, the right answer is: “I would like to have application that is secure and works.”

Having in mind that Windows Azure OS is still quite “young”, giving the control to the customer may not be such a bad idea. The best approach though would be to have at least the option to choose some level of auto-upgrade (on a patch level or minor version level). Of course this will come soon as the team recognizes the need for that.

How to specify Windows Azure OS Version?

As you can read from the MSDN documentation you can set the osVersion attribute in the service configuration (CSCFG) file if you want to specify the Windows Azure OS Version for your VM. In order to find out what are the possible values for osVersion attribute you need to look at the article specific to the OS version you want. The best starting point is the OS/SDK Compatibility Matrix - all Windows Azure OS versions are listed in the navigation tree under that article.

 

 

The osVersion attribute accepts values in the following format:

 

WA-GUEST-OS-M.m_YYYYMM-nn

 

Where:

• WA-GUEST-OS is a fixed string
• M.m are the major and minor versions
• YYYY is the year
• MM is the month
• and nn is a sequence number used to differentiate releases within a month if necessary

 

This string is mapped to user friendly string with the following format:

 

Windows Azure Guest OS M.m (Release YYYYMM-nn)

 

Where all the letters have the same meaning as above. Examples for osVersion attribute value and friendly name are:

 

WA-GUEST-OS-1.0_200912-01
Windows Azure Guest OS 1.0 (Release 200912-01)

 

What happens if you don’t specify Windows Azure OS Version?

There are several options to update the CSCFG file and hence to specify the osVersion attribute in it. However, if you don’t specify OS Version in your CSCFG file a “default” version will be selected for you, and osVersion attribute will be added to your service configuration file. This happens in the following cases (either through the Portal UI or through the management APIs):

• When you create new deployment
• When you change your service configuration
• When you upgrade deployment (see below for this one!)

Upgrade deployment is a special case tough, because you can upgrade the whole service or just one specific role. If you upgrade the whole service the behavior is the same as for new deployment and change of configuration. If you upgrade only particular role from the service then your OS version will not be changed. The reason for that is that OS version applies to the whole service, and not to a particular role.

What “default” means is up to Windows Azure team to decide. In general the goal is to have the latest version as default but this is not guaranteed.

Other things to watch for when specifying Windows Azure OS Version

Besides the security patches and bug fixes there is one more thing quite important to watch for, when specifying OS version for your VM. This is the OS/SDK compatibility as described in the MSDN article Windows Azure OS Versions and SDK Compatibility Matrix.

Sometimes features exposed through the SDK may need specific OS in order to work – good example for this is XDrive that was released with the latest SDK. If for example you want to use XDrive in your application you need to target Windows Azure OS 1.1 because it will not work on the earlier version.

Using Windows Azure PowerShell Sample to Investigate Issues with Cycling Roles

After posting Windows Azure Deployment Stuck in Initializing, Busy, Stopping – Why? two weeks ago, I received quite useful feedback from colleagues in our support centers. It is related to the problem with the missing DLLs that may cause your role to be cycling between those states.

 

Retrieving a List of Available DLLs on the Guest VM

If you want to check whether particular DLL is available on the VM your role is running on, you can use the PowerShell sample that comes with the SDK.  In order to do that you need to deploy the sample, and type the following command in the script box:

 

dir d:\ -include <name of file> –recurse

 

If for example you want to check whether System.Data.DLL is available on the VM you should type:

 

dir d:\ –include System.Data.DLL –recurse

 

and somewhere in the results you will see something like this:

 

Directory: Microsoft.PowerShell.Core\FileSystem::D:\Windows\assembly\GAC_64 \System.Data\2.0.0.0__b77a5c561934e089

Mode    LastWriteTime         Length     Name

----    -------------         ------     ----

-a---   4/11/2009 4:12 PM     3008512    System.Data.dll

 

This means that System.Data.DLL is available in D:\Windows\assembly\GAC_64 folder. You can ignore the majority of the output that shows “access denied” because you don’t have access to those folders anyway.

 

OS Version Dependencies

One thing to pay attention here is the OS version dependency. As you already know Windows Azure introduced Operating System Versioning in Windows Azure back in December 2009 (I may post some OS specific clarifications in the future), and there may be differences in the DLLs included in the different OS versions.

Make sure that you deploy the PowerShell sample on a VM that runs the same Windows Azure OS version as your application.

 

Checking References in Visual Studio

Here is one more way you can use to check whether the DLL is available on the VM. If you reference DLLs from .Net Framework 2.0 or 3.5 you can be sure those are available on the VM. You can check this in Visual Studio with expanding the References node under your role and selecting particular reference. In the Properties window find the Path property, and verify whether it is under one of the following folders:

 

C:\Windows\Microsoft.NET\Framework\

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\

If the reference does not point to a DLL under one of those two folders you need to set the Copy Local property to true.

 

Special thanks to Kevin W. from Microsoft support center in Las Colinas and William B from Microsoft support center in Charlotte for this information.

Windows Azure Deployment Stuck in Initializing, Busy, Stopping – Why?

Recently I see a lot of posts on Windows Azure Forum related to deployments cycling between Initializing, Busy and Stopping states. In this post I would like to summarize the most common reasons why is this happening. Here they are:

• Missing runtime dependencies (DLLs)
  If you use libraries that are not includes in the standard .Net installation, you will need to include those in the package and deploy them together with your roles. In order to do that you need to set the Copy Local property of the reference to True.
  Here is how you do this in Visual Studio 2010 (see screenshot below):
  • Go to Solution Explorer and expand the Role tree
  • Select the reference you want to add to your package
  • In the Properties window for this reference change the value of Copy Local to True
     
• Using incorrect platform version of a DLL
  The OS running on Windows Azure VMs is 64 bit, and although you can start process that uses 32 bit assemblies you should NOT reference 32 bit assemblies from a Web or Worker role.
• Your code or assembly you use requires admin access (elevated privileges)
  Although your application may be running under Full Trust some calls or assemblies may require elevated privileges. Admin access is currently not supported in Windows Azure, and such calls will fail.
• Misconfigured DiagnosticsConnectionString in Service Configuration file
  There are a couple of issues you may hit here:
  • By default the string points to Development Storage. When deploying to the cloud you need to make sure the string points to a storage account in the cloud.
  • Starting diagnostics without specifying DiagnosticsConnectionString. The reason this will not work is obvious.
  • Using brackets when specifying protocol. Apparently some blog post states that the protocol should be within square brackets, which is not true. The right format for specifying the string is the following:
    
    <Setting name="DiagnosticsConnectionString" value=”DefaultEndpointsProtocol=https; AccountName=myaccount; AccountKey=mykey" />
    
    
  • Using HTTP as endpoint protocol. You should use HTTPS as an endpoint protocol for Diagnostics.
• Misconfigured DataConnectionString in Service Configuration file
  You should check for the same things as described above for the DiagnosticsConnectionString.
• web.config or app.config issues
  Those can be:
  • Invalid settings in web.config/app.config files
    One good example for such is using wrong providers.
  • Malformed or invalid XML
• Wrong CSDEF and/or CSCFG schemas
  Although very unlikely your Service Definition or Service Configuration files may be invalid. Normally Visual Studio will show error if one of those files doesn’t comply with the schema, but if you use other tools or create the package manually those may not get validated.
• Read from queue or table that doesn’t exist during initialization
  Make sure all storage tables and queues are created prior starting the application, and any configuration data is populated in those.
• Certificate without exportable private key 
  In order for your certificate to work in the cloud it needs to have exportable private key. Certificates without exportable private key are not supported. If you use Windows Certificates Manager you need to make sure to select “Yes, export the private key” option while exporting the certificate.
• Returning from Run() method in a Worker Role
  Windows Azure expects that you never return from Run() method. If you do so it considers it as an error condition and restarts the role.
• Uncaught exception thrown during initialization
  There are endless possibilities here, therefore make sure you catch every exception during initialization and log it properly.
  

Suggestions

Here are few suggestions that may help you if you hit this problem:

• Make sure your code runs in Development Fabric and Development Storage
  This is the first step you need to try but be aware that this test will not catch things like admin access (normally you are admin on your development machine) or wrong connection string.
• Use the diagnostics feature to trace your application
  If you don’t modify the generated code about diagnostics, errors will be traced automatically. Trace information is stored to the cloud storage on a regular basis. If your DiagnosticsConnectionString is configured properly to use cloud storage you should be able to find the traces in the WADInfrastructureLogsTable table.
• If feasible delete and redeploy you application in the cloud
  Sometimes your deployment may get stuck for no obvious reason. One way to solve it is to redeploy the service. If this is not possible you need to contact Windows Azure support team for assistance.

 

References

Here are few other blog posts that give more details about some of the issues described above:

Windows Azure role stuck in Initializing/Busy/Stopping [Anton Staykov’s Blog]

Another common reason for Windows Azure role stuck in Initializing/Busy/Stopping [Anton Staykov’s Blog]
Windows Azure: why is my service not starting? [Guy Shahine’s Blog] 

 

Hopefully this information will make it easier for you to track down issues with your deployments.

Subscription and Service Administration in Windows Azure

On January 4th 2010 Windows Azure announced that you can start upgrading your CTP accounts to paid commercial subscription (see Sign up for a Windows Azure platform offer today and get visibility into your usage on Windows Azure Blog). In this post I would like to give you short introduction of the different roles available, as well as to point out certain limitations, and what to look for when migrating your CTP account.

Those of you who already migrated their CTP subscriptions know that the subscription administration is done in Microsoft Online Commerce Platform (MOCP), while service administration is done in the corresponding developer portal (in my case this will be Windows Azure Developer Portal). The steps you need to follow in order to upgrade your CTP subscription to paid commercial one are the following:

• Go to Microsoft Online Commerce Platform (MOCP)
• Sign-in with your Windows Live ID
• Select an offer and provide your credit card details
• Designate Service Administrator account

When you complete the process you can login with the Service Administrator Live ID to Windows Azure Developer Portal (if you have selected Windows Azure subscription of course) and you will see the new subscription.

Account Administrator and Service Administrator

First of all I would like to clarify two terms: Account Administrator and Service Administrator. What those two mean?

• Account Administrator (AA) (also known as Account Owner) is the person who manages the subscription (or subscriptions) in MOCP. In general this is the person who is responsible for paying the bill, and normally has financial responsibilities in your company.
• Service Administrator (SA) (or also Service Owner) is the person who manages the service that runs in the cloud (or Windows Azure, Microsoft SQL Azure or Windows Azure platform AppFabric). You can think of him or her as the IT person or developer who is responsible for the service operation.

With the introduction of those two roles you are able to separate the financial responsibilities from the operational responsibilities for your cloud account.

Limitations

There are certain limitations that some of you may find restrictive. In general they fall into two categories:

• Granularity of access – Service Administrators are not able to delegate certain tasks in the developer portal to another person (i.e. LiveID), which makes the Service Administrator the only person who can manage the service.
  By the way the same is true for the Account Administrator – there is no possibility to delegate the administration of particular subscription to another person.
• Multiple access – for both the subscription administration and service administration you are not able to designate more than one person (i.e. Live ID).

CTP account migration

As part of the sign-up process in MOCP your CTP account may be migrated. What that means is, that your hosted services and storage accounts associated with your CTP account will be assigned to the newly created paid subscription. However, in order this to happen you need to do the following:

• You need to use the same LiveID for Account Administrator as the one you used to sign up for the CTP account. I.e. when you sign up to MOCP use the same LiveID you used to sign up for CTP acocunt on the corresponding developer portal.
• Once you sign-up for the paid commercial subscription, and verify in the developer portal that your account is migrated, you can return back to MOCP and designate another LiveID for Service Administrator.

Additional to that if you have more than one CTP subscription only the first one you created will be upgraded.

I hope this information will help you migrate your accounts smoothly.

Windows Azure Role Instance Limits Explained

In preparation for the Windows Azure Commercial Launch new limits for role instances were introduced. Those differ from the currently available Customer Technology Preview (CTP) limits, and may impact the way you deploy and configure your hosted services or storage accounts in Windows Azure.

This article explains what the relationship between the number of hosted services, number of roles, number of instances, VM (Virtual Machine) size and deployments is (for more details on the VM sizes visit Configuring Virtual Machine Size on MSDN). Additionally you will get an overview of what the limits for storage accounts are.

If you have already encountered issues with your deployments you should follow the guidelines below to calculate your needs and call Windows Azure Support team for assistance.

Here is a brief overview of the current and future limits imposed on your services in Windows Azure.

	Effective before Dec. 10th 2009	Effective  after Dec. 10th 2009	Effective after Jan. 4th 2010
	Token (CTP)	Token (CTP)	Token (non-billing country)	Paying subscription
Deployment Slots	2	2	2	2
Hosted Services	1	1	20	20
Roles per  deployment	5	5	5	5
Instances per Role	2	2	no limit	no limit
VM CPU Cores	no limit	8	8	20
Storage Accounts	2	2	5	5

CTP Program Limits

CTP program was free, but in order to participate you were required to request a token. One token entitled you to the following deployments:

• 2 deployment slots (1 production and 1 staging)
• 1 hosted service
• 5 roles per deployment
• 2 instances per role

In total this allowed you to have up to 20 instances deployed for free. Additional to that you were entitled to have up to 2 storage accounts, 50GB each.

If you were lucky to get additional CTP tokens you could “stack” those and easily double (or triple, quadruple etc.) the limits above.

The size of the VM was not considered into account when calculating the CTP limits. What this means is that you can configure your roles to be deployed on extra large VMs (8 CPU cores, 15 GB RAM, and 2TB local storage), and still deploy 20 instances for free, making it 160 CPU cores in total.

In summary the CTP program was a good way to consume large amount of resources for free.

Commercial Launch Limits

However, getting those free resource is not possible anymore. The new limits are already fact, and starting January 4th those will be different for customers who use tokens and customers who convert their subscription to billing. Those will be calculated using weighted formula that takes into account the size of the VM too. The weighted formula counts the number of CPU cores you use for your hosted service and limits your usage based on this number.

If you happen to be in a country that is not provisioned for billing for Windows Azure you will still be able to use tokens and deploy your application on Windows Azure. Of course those tokens will be controlled much more strictly than until now, and the corresponding limits will be consistently enforced.

What the numbers above mean? Don’t be mislead by the number 20 for Hosted Services. Theoretically you will be able to create so many, however you will hit the limit of VM CPU cores much earlier. Here is how this works.

Imagine you create Hosted Service with two roles in it, and each role has one instance with Small VM Size (1 CPU core). The math is as follows:

1 hosted service x 2 roles x 1 instance x 1 CPU core = 2 CPU cores

You have already used 2 out of your 8 allowed CPU cores with just one instance. If you decide to replace the VM size with Large one  (4 CPU cores) you will reach the limit:

1 hosted service x 2 roles x 1 instance x 4 CPU core = 8 CPU cores

Thus you can easily reach or exceed the limit with only one Hosted Service.

The other number you should be careful with is the number of roles per deployment. You are entitled with up to 5 of those independent of the type (Web or Worker). Imagine you design your service to have 5 roles with 1 instance on a small VM each (not very redundant but this is for the purpose of illustration only). Imagine also that you want to use the staging environment for your pre-production tests, and you want to mimic exactly your production environment. If you have already your previous version deployed in your production slot, you will exceed the limit of VM CPU Cores when you try to deploy your new version on the staging slot (assuming you have limit of 8 CPU cores):

Prod Deployment = 5 roles x 1 instance x 1 CPU core = 5 CPU cores

Stage Deployment = 5 roles x 1 instance x 1 CPU core = 5 CPU cores

Total = 10 CPU cores

One thing to remember is that stacking tokens will not increase your limit as it will just increase the number of allowed Hosted Services but not the number of CPU cores you are entitled to. However stacking tokens will still give you more storage accounts. Of course this may change in the future.

Because the goal is to convert CTP users to paying users, billing subscription will have higher limits for compute, which is set to 20 by default. Also billing users will be able to call Windows Azure Support team, and request increase of their limit as long as they provide enough business justification and money guarantee.

Errors Thrown When Exceeding the Limit

If you happen to exceed the limit of VM CPU cores you will be presented with the following error in Windows Azure Portal:

The subscription policy count for resource was exceeded. Please visit the Accounts tab to learn how to increase your resource quota Dr. Watson Diagnostic ID: 89ac8ae2-c5a8-48ae-a7d6-751db6bdf22a

Similar error will be returned from the Service Management API.

Keep in mind that you will receive the above error in the following cases:

• When you try to re-deploy your service (change the number of roles or the size of the VMs in csdef, or if your current usage is higher than the limit)
• When you try to increase the number of instances for your service (in cscfg), which can also be part of the upgrade

If you happen to exceed the limit of roles per deployment you will receive the following error:

Unsupported number of roles Dr. Watson Diagnostic ID: 5cbd9c72-3f27-4f31-a54f-bfb100b92516

This error you will only receive if you try to re-deploy your hosted service.

Your service will not not impacted if you try to run or suspend it. If you already have running service that exceeds the limits above it will not be impacted either, but you need to make sure that you request increase of your limits before your next deployment.

One more thing is that stopped services count towards the limits. Stopping your application on staging will not help you if you want to increase the count on your production service; you will need to completely delete your staging deployment in order to free up some slots.

What is next?

All customers who reside in the billing countries will be required to migrate their CTP subscription to a billing one in January 2010. One thing you need to be aware of though is that during the migration process the limits will be reset to the above mentioned ones.

The best approach you can take is to wait until January and migrate your CTP subscription to a billing one first, and then request increase of your limit if you need to. Thus your service will continue to run uninterrupted. Of course you can do this only of you don’t plan any deployments that exceed the limits before January.

At some point of time after February 1st 2010 all CTP tokens in the billing countries will be evicted. Even when evicted you may be able to continue to run your service, but you will be prevented to do any deployments and upgrades.

More Resources

Additional information about the limits is available on RemyP’s blog and in BradC’s talks from PDC09.

Storage Quotas and Core Allocation on Windows Azure[RemyP’s Blog]

New role instance allocation[RemyP’s Blog]

Windows Azure Blob and Drive Deep Dive[Brad Calder]

Building Scalable and Reliable Applications with Windows Azure[Brad Calder]

Cloud Storage Tools

In this post I am going to second what Remy wrote in Windows Azure Storage Made Easy, and will add one more tool as well as my own experience and preferred choice. Here is the list of the tools I looked at:

• CloudBerry Explorer for Azure Blob Storagefrom CloudBerry Lab Inc.
• Cloud Storage Studio from Cerebrata Software
• Azure Storage Explorer from Neudesic
• and the OpenSource SpaceBlock

All of those tools provide graphical user interface for managing data stored in Windows Azure Storage.

 

CloudBerry Explorer for Azure Blob Storage

CloudBerry Explorer for Azure Blob Storage is a pretty neat tool that gives you the possibility to copy files from your local machine to the cloud and vice versa using familiar explorer interface. It also offers tabs, allowing you to open different local folders and remote storage accounts.

Another nice feature is Synch Folders – you can set up synchronization between a local folder and container in your storage account, and keep those in synch for as long as CloudBerry is running (you can minimize CloudBerry window to keep it resident in memory - it will clear your taskbar area, and show only the system tray icon).

Initial Experience

One annoyance that I noticed was the first run experience with the registration prompt. The process was quite confusing. First, I still don’t understand why I had to provide username but never use it after that.

And second, I find it hard to copy the long cryptic registration key from my web based email and paste it in the registration box.

Also for some reason F1 help never came up for me. I know I am old fashioned but I spent some time working on Windows Help, and apparently lot of people still use help. If you have the option you better make it work.

My sincere suggestion to the developers from CloudBerry Lab is to rethink the registration workflow but once you get past that CloudBerry is pleasure to use.

Limitations

CloudBerry Explorer for Windows Azure Storage can be used with Windows Azure Storage only. You cannot access storage services from other providers using the tool.

Additionally you cannot browse table and queue information with this tool.

 

Cloud Storage Studio

Cloud Storage Studio certainly provides much more functionality than CloudBerry Explorer – you can browse blobs, queues and tables. Surprisingly for me you can also manage hosted services with it (hence the name doesn’t match completely:)).

Cloud Storage Studio provides rich functionality to manage your Windows Azure Storage and Hosting Services directly from your desktop.

Initial Experience

Although I was pleasantly surprised by the richness of functionality in Cloud Storage Studio, my initial experience wasn’t great. Every task that you perform requires new pop-up window that either has several tabs or bunch of buttons. The upload window didn’t fit on my laptop’s screen with resolution 1024x768, and there was no way to resize it or move it. In order to upload a file I had to guess what the labels on the buttons are (see screenshot below).

My personal opinion is that the UI is not usable on a machine with such or lower resolution.

Additional to that the UI is cluttered with toolbars and icons that show up in different places, and add to the confusion.

Limitations

Cloud Storage Studio is another tool you can use with Windows Azure only. If you can get over the lack of intuitiveness in the UI you can completely manage your Windows Azure accounts (Storage and Hosting) with it.

 

Azure Storage Explorer

Unfortunately I cannot say any good words for Azure Storage Explorer. Starting with the following error prompting me to start Azure Storage Explorer with admin privileges,

and going through the part that right-click doesn’t provide the option Run as Administrator (see below) made me thinking that Azure Storage Explorer wasn’t developed with Vista/Windows 7 security model in mind.

I was finally able to start it but even then the experience wasn’t great. After configuring my storage account I couldn’t get it working – every time I was getting the following error:

With all this I gave up but you may want to give it a try. As it came out later though (while trying the other tools) the creation of the blobs succeeded.

 

SpaceBlock

I have already used SpaceBlock for a while – mostly for viewing my storage account and transferring sample files. It has familiar Explorer interface with window divided in two for the two storage locations opened.

SpaceBlock provides complete functionality to manage containers and blobs in Windows Azure Storage Account.

Added benefit is that you can manage not only Windows Azure Storage but also Amazon S3, Nirvanix, SQL Server Data Services and Sun Cloud Storage accounts. You can also easily transfer data from one cloud account (S3 for example) to another (Windows Azure). Of course the data is downloaded to your local machine from the first account and then uploaded to the second one, and you are limited by your downstream and upstream connection speed.

Initial Experience

The tool is quite simple and learning the functionality is not hard at all. The UI can be improved a little but at least follows common patterns and is easy to navigate through. The icons are familiar, and rarely confused me.

One annoyance is that every time you do a transfer the focus switches to the Transfers tab – I would expect to have the right side pane updated with the name of the transferred file (for some reason unknown to me, none of the tools handled this well).

Limitations

SpaceBlock took another approach – they decided to provide basic storage management functionality for more than one cloud service. Thus SpaceBlock is limited to managing containers and blobs only in Windows Azure Storage.

 

Conclusion

Except Azure Storage Explorer, which I wasn’t able to test at all, all others can be of use for you – either for easy blob management (CloudBerry), tables and queues (Cloud Storage Studio) or migrate data from one cloud provider to another (SpaceBlock).

Give the tools a try and let me know what you think.

Your First Application for Windows Azure

Creating your first application for Windows Azure is quite easy – Windows Azure Tools for Microsoft Visual Studio will do all the work for you. Here the steps.

Developing Hello Windows Azure Application

1. Start Visual Studio 2010 (currently in Beta 2) in elevated mode:
   
   
   
   If you start Visual Studio in non-elevated mode you will be prompted to do so later on, when you try to run your application in Development Fabric.
2. Once Visual Studio 2010 is started select New Project and in the Installed Templates tree on the left, under Visual Basic and Visual C# you will find the option Cloud Service.
   
   
   
   Select .NET Framework 3.5 from the drop down because currently Windows Azure doesn’t support .NET Framework 4.0. Type the name of the project (HelloWindowsAzure in our case) and click OK.
   
3. You are presented with a second dialog box where you can select the type of the role you want to develop. You can select from the following types:
   ASP.NET Web Role
   ASP.NET MVC 2 Web Role
   WCF Service Web Role
   Worker Role
   and CGI Web Role
   All of those can be developed in C# and Visual Basic; Worker Role can also be developed in F#. For our simple application you can select ASP.NET Web Role:
   
     
   
   You can click on the pencil icon and change the name of the role to something more meaningful like HelloWindowsAzure Web Role for example.
4. Once you confirm the dialog your project is created and the Default.aspx file is open in the UI. The only thing you need to do is type
   
   Hello Windows Azure
   
   Between the <div> opening and closing tags.
   
   

Deploying the Code to Development Fabric

Development Fabric is the local environment that takes care of the deployment of your application and manages the resources for it. Deploying your app is quite easy:

1. Right click on the project and select Build to make sure your project has no compilation errors
   
   
   
2. Once the project is build select Debug –> Start Without Debugging (or alternatively you can press Ctrl+F5) from the menu bar.
   
   
   
   Of course Visual Studio will build the project once again, launch Development Fabric and submit your application for deployment. You will know when Windows Azure Simulation Environment containing Development Fabric and Development Storage is started when you see the balloon and the icon in the notification area.
   
   
   
3. Your default browser window will be opened automatically and you will see the default page of your application
   
   
   
4. If you are curious you can right-click on the Windows Azure Simulation Environment icon and select Show Development Fabric UI
   
   
   
   Development Fabric UI gives you details about your application (also called Hosted Service as you already know:)), which will be very useful in the future for debugging.
   
   

Deploying Your Application to the Cloud

Once you are done with the development and testing of your application you may decide to deploy it to the cloud so everybody can see it. Once again this it done quite simple from the Visual Studio UI.

1. You can right-click on the project and select Publish or alternatively select Build –> Publish from the menu bar
   
   
   Although not perfect the workflow helps you a little with the deployment of your application. Visual Studio does two things for you:
   
   • Opens the folder where Windows Azure package (cspkg) and configuration (cscfg) files are in Windows Explorer
     
     
     
   • Opens your default browser and loads Windows Azure Developer Portal in it
     
     
     
2. In Windows Azure Developer Portal you need to click on your project and select the New Service link in the upper right corner
   
   
   
3. On the next page click on Hosted Services
   
    
4. You need to fill in Service Label and Service Description and click Next
   
   
   
5. On the next page you will be prompted to specify the Public Hosted Service URL that contains the Public Service Name as well as the Hosted Service Affinity Group. You can leave the Affinity Group unchanged because we are not concerned about geo-location for now.
   
   
6. When you click Create your Hosted Service will be created. The Hosted Service hosts your application.
   
   
   
7. Click on Deploy button and on the new page select the Windows Azure package (scpkg) and configuration (cscfg) files using the Browse buttons. Also type a name for your deployment – this name is used for visual clue in the UI.
   
   
   
8. Once you click Deploy your files get uploaded and then deployed on Windows Azure. Depending on the size of your files and the number of roles it may take several minutes to have the application deployed on Windows Azure.
   
   
   
9. Once the application is deployed you need to click on Run to start it. It will show Ready once it is running.
   
   
   
10. Now you can access your Hello Windows Azure application clicking on the Web Site URL
    
    

Summary

To summarize here is what the above process described:

• Create Windows Azure Cloud Service project in Visual Studio 2010
• Create Web Role in the Cloud Service project
• Modify Default.aspx page in the Web Role
• Deploy the service to the local Development Fabric
• Access the local service via the browser
• Deploy the service to Windows Azure
• Access the service on Windows Azure via the browser

In the explanations above I used Hosted Service and application interchangeably. The official term in Windows Azure is Hosted Service, and it can contain several Web and Worker roles. Because Web Application is more familiar for Web Developers and we developer simple Web Role I allowed myself the freedom to do that.

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!

 

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:

 

Clicking on Manage forwards you to the configuration page:

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

 

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:

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.

 

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

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.