To recap, this 2 part blog series outlines the variety of options you have to connect Azure applications to components not hosted in Azure. Notice that I specifically did not say on-premises, I get into lots of questions about migrating to Azure, mainly around migrating from another cloud provider like Amazon or Rackspace. The reality is that you can host a portion of your application in Azure and keep the remaining parts on whatever provider, or on-premises. Take iCloud for example, there is evidence (unconfirmed of course) that it uses both Amazon and Azure services.
In part 1, I talked about Data layer and Application layer integration. Here I will briefly cover the final two types of machine and network layer integration options.
This option uses a piece of software installed onto the machines called Windows Azure Connect. Some may claim that Azure Connect has been depreciated now that the site-to-site connections are available, I would argue that there are situations where you do not need an entire network connected, simply a single machine. This is helpful when integrating with a monolithic, age old on-premises machine that cannot be moved. Once the Azure Connect software is installed and configured on the machine it can easily communicate with any number of other roles configured in the virtual network. Note that this does not give the roles access to your entire network, only the machine with the software installed.
To get access to this functionality you need to venture back to Silverlight land and the old portal. I am not sure what Microsoft plans for this feature but I hope it can become as easy to use as the site-to-site networks with the new HTML5 portal.
At this point the Virtual Network is the newest feature to round out the Azure integration scenarios. This was released with the Infrastructure-as-a-Service features in the “Spring Release” (June 2012) of Azure. Windows Azure Virtual Networks provide the capability to treat Azure like a remote datacenter. Using an VPN connection, all network traffic can be routed between the two locations as if they were in fact in the same place. There has been lots of movement in this space, not only because it is a new feature of Azure, but it provides “branch office” functionality which is very familiar to most IT departments of larger organizations.
Unlike Cloud Services or Virtual Machine groups, the Virtual Network does not provide DNS for the machines, once you start adding machines to a VNet you need to provide your own DNS server. That server could be hosted in the VNet in Azure or over the VPN tunnel in your datacenter.
Virtual networks are connected to Affinity Groups in Azure. Which means that other services (storage and cloud services) can be associated to the group. A Cloud Service in the same affinity group even has network access to the virtual network which helps in a number of scenarios where you may be building new services that depend on existing VM installed components.
Site-to-Site connectivity may be the least intrusive to your application however it is the most difficult to setup. If your datacenter does not use VPN tunnelling it could mean new appliances from Cisco or Juniper and maybe some help setting up and maintaining the network appliance. However, the cost savings of going to Azure for IaaS hosting could be well worth it.
Well that about all I have for now. Be sure to check back for technical implementations of these scenarios with applications like SharePoint, TFS, and Active Directory.
Thanks for reading.