I published another blog post describing the status of affinity groups in July 2014.
Windows Azure Datacenters
Microsoft has built out 8 Windows Azure datacenters in 3 geographical regions across the World. They are located in:
- North America
- North Central US
- South Central US
- East US
- West US
- North Europe
- West Europe
- East Asia
- South East Asia
These datacenters are widely separated so that inter-datacenter latency is significantly higher than intra-datacenter latency. There is little that can be done about inter-datacenter latency since much of it is caused by the speed of light being a finite physical constant. Unless there is a specific reason for doing otherwise cloud services and any data they access should always be located in the same datacenter.
It used to be possible to specify a US | Europe | Asia Anywhere designation when allocating a cloud or storage service. The problem with this designation was that it was not clear where everything ended up and it was possible that associated cloud and storage services were actually located in different datacenters in the same geographical region. Fortunately, this choice has now been removed. However, if you created cloud and storage services using the Anywhere designation it is worth verifying their actual physical location.
Windows Azure datacenters are physically very large (think 7 football fields) and contain hundreds of thousands of servers. There is a significant difference in network latency between two servers in a single rack and two servers at opposite ends of a datacenter.
Windows Azure therefore provides an affinity group feature to provide a higher degree of co-location within a datacenter than would otherwise be possible using random placement. Associated cloud and storage services should be placed within an affinity group to minimize network latency. This minimization is particularly important when a cloud service makes extensive use of storage services, such as when an Azure Drive is used.
Note that affinity groups are supported for cloud services and storage services but are NOT used with Windows Azure SQL Databases. As of today they are also not supported for Windows Azure Web Sites and Virtual Machines.
Since an affinity group is located within a single datacenter, locating cloud and storage services in an affinity group also ensures that they are located within the same datacenter. New cloud and storage services should always be created within an affinity group rather than just the datacenter. Note that it is not possible to migrate either a cloud or storage service into an affinity group after creation. Migration into an affinity group requires a recreation of the cloud or storage service/
Affinity groups are created and managed on the Windows Azure Portal for cloud and storage services. On the new portal, affinity groups are managed in the Networks section when creating a new Virtual Network. Given the above description of affinity groups this might seem to be a strange location. However, the new Virtual Network feature mandates the use of affinity groups.
The Virtual Network feature (tutorial) currently in preview on Windows Azure and accessible through the new portal also uses affinity groups. However, this use is mandatory for virtual networks while it is only advisable for cloud services and Windows Azure storage.
Every virtual network resides in its own affinity group and only one virtual network can be associated with any affinity group. The cloud and storage services contained in the affinity group can then be associated with the virtual network in a manner that maximizes co-location of the services and minimizes network latency inside the virtual network.
When using the Wizard to create a virtual network either an existing affinity group must be provided or a new one created using the Wizard. If the virtual network is created by importing a configuration file then the affinity group must be created before the file is imported.
On June 7, Microsoft released into preview many new features for Windows Azure. The two most significant features announced and now available for trial were:
- Virtual Machines
- Web Sites
Until now, the compute services provided by Windows Azure were exclusively platform-as-a-service (PaaS)) which essentially provides a highly-scalable application hosting environment. The Virtual Machines feature is a fully-featured infrastructure-as-a-service (IaaS) offering provides the capability to deploy Windows Server and Linux servers on which enterprise-class software – such as SQL Server 2012 and SharePoint 2010 – can be deployed. Virtual Machines allows a significant expansion of the class of workloads that can be deployed to Windows Azure.
Web Sites provides a scalable, multi-tenanted web site hosting capability that is integrated with a wide variety of developer tools. This significantly broadens the developer support for creating and deploying web sites into Windows Azure, since it avoids the overhead necessary to use web roles for simple web sites. The new Web Sites feature is aimed at applications which do not require the high scalability and sophisticated feature set provided by cloud services.
This is a great time to be working with Windows Azure and either developing green-field applications or migrating existing applications to the platform. You can access a 90-day free trial here. If you are an MSDN subscriber you can access $3,600 of Windows Azure benefits here. You can access the SDKs from here – and these exist for .NET, node.js, PHP, Java and Python.
Microsoft has allied with TechStars to provide an incubator in Seattle, WA for Windows Azure. Applications are open now for the Fall session. The incubator provides $20,000 in seed funding and $60,000 in Windows Azure resources as well as office space, technical training and support.