It’s Getting Tight

In my last blog post I shared about how I use a Microsoft Azure Virtual Machine as my development machine. It’s been a month since I made this drastic change, and I must admit that it’s been pretty cool! The Azure Virtual Machine has provided me with more agility in my hectic schedule. I’ve been able to start my day from one machine, move to a different machine and continue from where I left off. I no longer deal with putting my machine to sleep or trying to remember where I was when I left off. When I log off from one machine, I log back in right where I left off.

As I move from project to project, the resource requirements vary, and sometimes I need more resources. Fortunately, we can scale our Virtual Machines up and down through PowerShell and the Azure Portal.

Windows Azure Table Storage Service – Migrating Tables Between Storage Accounts

Building on top of the code from my post “Windows Azure Blob Storage Service – Migrating Blobs Between Accounts” I added logic so that the Windows Azure Storage Account migration process recreate all the Tables from the source account in the target account. Then It downloads the entities from the source Tables using segmented table queries and inserts(or replaces) them into the target Tables.

The process is surprisingly fast compared to the migration of blob containers. When we copy a blob from one container to another, a command is queued and it can take some time to complete. Migrating Tables on the other hand, requires significantly more bandwidth, because we need to download the data from the source Tables and upload it into the target Tables located in the target Windows Azure Storage Account.

Entities are downloaded 1000 at a time. Then they are fed into my TableStorageWriter, which regroups the entities by Partition Key and inserts them in batches of 100.

Windows Azure Blob Storage Service – Migrating Blobs Between Accounts

I recently created a Windows Azure Storage Account without an Affinity Group and was faced with the task of migrating the data to a newly created Windows Azure Storage Account which belongs to the Affinity Group used by the project’s Cloud Services.

By physically grouping Cloud and Storage services together, Affinity Groups contribute to the overall performance of your application by reducing network latency. Consequently it reduces the amount of time a CPU remains idle waiting for files to process. It may not seem important at first, but it makes a world of difference for compute intensive worker roles who depend on Windows Azure Storage for IO.

Migrating data can be achieved in a couple of ways

• Download the data and upload the data to the new Storage Account. (This is by far the option that takes the longest time)
• Use tools like Azure Management Studio (Some of these solutions cost money)
• You can make your own tool