One of the preview feature that Microsoft release in June 2012 was the Virtual Network Preview, before this the only choice for connection your Azure services to your on-premises resources was Azure Connect. Azure Connect was a good solution for point to point connections, but had several limitation around domain controllers and windows clustering.
With the June 2012 release of Azure Virtual Networking we were now able to connect a set of Azure services to our on premises network via an IPsec VPN. In the preview there is only a subset of 2 hardware vendors devices supported, Cisco and Juniper, but there have been some blog posts detailing how to setup the Virtual Networking to Microsoft TMG server. Not having access to a hardware firewall supported by Azure Virtual Networking, I decided to give the TMG solution at try. I attempted to use the TMG server from our Mexia Infrastructure, but being located behind another firewall that does not allow IPsec VPN connectivity, it would not connect. I then embarked on installing TMG on my home network as a virtual machine, actually not as difficult as you would expect, I had prior experience with both TMG and its predecessor ISA.
I was then able to establish the VPN, but ended up with having to enable the NAT feature on the IPsec VPN and only able to communicate in one direction, from Azure to my on premises machines. For the tests I was planning this was good enough. I then created a virtual machine in the Azure Virtual Machine preview and select a subnet that I had created during the virtual network configuration on the Azure side. I was then able to join the new machine to my domain and logon with my domain credentials, 1st hurdle solved.
I next created a small application that loaded a number of BizTalk Tracking database (the only database I had with a reasonable number of records in it) records into a dataset, I then ran the test on the machine with the SQL server for BizTalk. The results for the local SQL server were as I expected sub second response for 1000 records. I then tested it on another machine in the same network and other than the initial connection taking just under a second longer, the other results were almost the same as being on the SQL server. The next test was running the same test on the Azure Virtual machine, the test program was using windows authentication so that worked perfectly since the Azure Virtual machine was domain joined. The test results were a bit slower than I expected, the initial test was about 8 times slower than being on the SQL Server, which amount to 8 seconds to retrieve 1000 records, after the initial retrieval it did drop down a bit but only to the high 5 seconds low 6 seconds. Not impressed with the speed, I tried retrieving 10 records, that dropped the time to around 1.5 seconds, So it seem that the biggest factor is actually moving the data. Given that I am on a standard ADSL2 connections, that could account for some of this delay.
For me these test have highlight several issues, some related to the virtual networking and other related to the fact that the Azure Data Centre is not located in Australia. First, I think there needs to be a wider range of devices both hardware and software supported for the Virtual Networking, I can understand how this is going to be a support nightmare, but at least publish the required setting and have some addition diagnostics when things don’t work. I have actually found a couple of under $500 ADSL2 routers that look like they support the same configuration as I used for TMG, now to just get my hands on one of them.
Secondly, I think the amount of data that is going to need to traverse the connection between your on premises data centre and the Azure Virtual Network is going to be the key factor to being able to build a responsive and usable hybrid solution, I also think that SQL data sync will need to be an integral part of any hybrid solution.
Lastly I am disappointed in the latency, encountered getting from Australia to any of the Azure Data Centres, I did a quick test from a virtual machine I have hosted in the US by Rackspace and the latency to the 4 US Azure Data Centres was at most 1/3 for the latency from Australia and in one case it was almost internal network latency of under 3 ms. I don’t think this is an unsurmountable challenge for Australia, but we are going to have to do our hybrid solutions smarter and more efficient that the developers in the US and Europe.
