VMRole and Azure Connect (still not IaaS)

I`ve been playing around for a while.

It`s blue, and it`s called ‘Azure’.

I wanted to test the new VMRole feature together with Azure Connect.

Here are the various setups I have tested:

1)      SharePoint installed on VMRole – connected with On-Premise SQL server

2)      Self-Service-Portal (v.1) on VMRole – connected with On-Premise servers

3)      LOB application connected with On-Premise SQL server

Before I get started, I just want to be clear that Windows Azure – even with VMRole and Azure Connect, should not be considered as an IaaS solution. It`s just a simplified way to move your existing applications to Azure. Think of VMRole as another way to build and deploy your applications.

Because there are some requirements for this role.

1)      You need to install the Windows Azure Integration Services

2)      You should sysprep your VM before moving it to Azure

3)      Size the VM properly – including RAM and disk size (you will only get one partition up there. The additional partition is dedicated for ‘Azure-stuffs’)

Ok, with those requirements, - or limitations in mind. What can we get out of it?

Oh, I almost forgot. If you have logged into the windows.azure.com portal after you have migrated one or two VMs, you have probably noticed some options there. It is called ‘Reboot’, and ‘Reimage’. It does what it says. So remember that you`re uploading a so called ‘base image’. This image could be reimaged by Azure. Meaning that every modification you do to your VMs, would be lost whenever the reimage-process starts. That’s Azure`s way to keep your VM clean, healthy, and to fix the instance if it fails.

http://msdn.microsoft.com/en-us/library/gg466230.aspx

“An instance can be rebooted any number of times. Windows persists all data across reboots. When you reimage a server instance, it is re-created from the image, and any state that you have not explicitly persisted is lost. Data that is written to the local storage resource directory is persisted when a server instance is reimaged; however, this data may be lost in the event of a transient failure in Windows Azure that requires your server instance to be moved to different hardware.”

So if we have to consider our roles in Windows Azure as stateless, what could be preferred to run there as far as an IT-pro concern?

-Nothing, really. It`s still a Platform – as a Service solution.

But with the ‘stateless’ in mind, I tested some ‘stateless’ applications up there.

And this is the part where the skill of an IT-pro is relevant when it comes to Windows Azure.

1.       I deployed a VM in Hyper-V, joined it to my lab domain, installed The Windows Azure Integration Services, and also the applications needed.

2.       I uploaded the image to Azure (added the –skipverify option to the cmd)

3.       Created and deployed a new hosted service in Windows Azure, and enabled it for Remote Desktop

After the VM was uploaded, I needed to connect it to my on-premise servers.

1.       I installed Azure Connect on the VM in Azure

2.       I installed Azure Connect on the On-Premise domain controller

3.       I installed Azure Connect on the other necessary servers On-Premise

4.       Created a group in Windows Azure, and linked those VMs.

(To make this possible, you have to logon to the Azure portal and download Azure Connect token on every server that should connect to each other)

I should also mention that using Azure Connect made me to brush off my IPv6 skills. Yes, it communicates on IPv6. So to make it real smooth, I setup my lab to support IPv6 (Domain Name System Services, and created AAAA-records for the servers intended for this scenario, and added rules to the Windows Firewall).

The SharePoint scenario and LOB scenario had one thing in common. It was really slow.

Since my lab is located in Norway, the closest Azure Datacenter is located in Amsterdam. (I also tried the datacenter in Ireland). The ping latency was about 600-700ms. And for SQL-communication which operates in real time, it appeared to be very slow. But it worked.

Using the Self Service Portal appeared to be faster, since it only initiates the job from the portal, down to the server on-premise. I created a VM from Windows Azure, and was able to connect to it afterwards.

The moral here is that when you get the possibility to Remote Desktop onto a VM with full access – and even can connect it to your network, you really need to know the platform you`re dealing with.

You may be tempted to think that this would open the door to use Azure as an extension of your network. To confuse you even more – it could. But only for applications, not infrastructure.  

Cheers,