During Microsoft Ignite 2016 I attended a few Azure networking architecture sessions. Towards the end of the week, though, they did overlap some content which was not ideal. A key message was there though. An interesting bit of reference architecture information.

Of note and relevant to this blog post:

• Migrate and disaster recover Azure workloads using Operations Management Suite by Mahesh Unnifrishan, Microsoft Program Manager
• Review ExpressRoute for Office 365 configuration (routing, proxy and network security) by Paul Andrew, Senior Product Marketing Manager
• Run highly available solutions on Microsoft Azure by Igal Figlin, Principal PM- Availability, Scalability and Performance on Azure
• Gain insight into real-world usage of the Microsoft cloud using Azure ExpressRoute by Bala Natarajan Microsoft Program Manager
• Achieve high-performance data centre expansion with Azure Networking by Narayan Annamalai, Principal PM Manager, Microsoft

Background

For the last few years there has been one piece of design around Azure Virtual Networks (VNETs) that caused angst. When designing a reference architecture for VNETs, creating multi tiered solutions was generally not recommended. For the most part, a single VNET with multiple subnets (from Microsoft solution architects I spoke with) was the norm. This didn’t scale well across regions and required multiple and repetitive configurations when working at scale; or Microsoft’s buzz words from the conference: hyper-scale.

VNet Peering

At Microsoft Ignite, VNET peering was made generally available on September 28th (reference and official statement). VNET peering allows for the connectivity of VNETs in the same region without the need of a gateway. It extends the network segment to essentially allows for all communication between the VNETs as if they were a single network. Each VNET is still managed independently of one another; so NSG’s, for example, would need to be managed on each VNET.

Extending across regions VNET peering across regions is still the biggest issue. When this feature comes, it will be another game changer. Amazon Web Services also has VPC peering, but, is also limited to a single region. Microsoft has caught up in this regard.

Interesting and novel designs can now be achieved with VNET peering.

Hub and spoke

I’m not a specialist network guy. I’ve done various Cisco studies and never committed to getting certified, but, did enough to be dangerous!

VNET peering has one major advantage: the ability to centralise shared resources, like for example networking virtual appliances.

A standard network topology design known as hub and spoke features centralised provisioning of core components in a hub network with additional networks in spokes stemming from the core.

Larger customers opt to use virtual firewall (Palo Alto or F5 firewall appliances) or load balancers (F5 BigIP’s) as network teams are generally well skilled in these and re-learning practices in Azure is time-consuming and costly.

Now Microsoft, via program managers on several occasions, recommends a new standard practice of using the hub and spoke network topology and leveraging the ability to centrally store network components that are shared. This could even extend to centrally store certain logical segmented areas, for example a DMZ segment.

I repeat: a recommended network design for most environments is generally a hub and spoke leveraging VNET peering and centralising shared resources in the hub VNET.

Important

These new possibilities offer awesome network architecture designs that can now be achieved. Important to note though, is that there are limits imposed.

Speaking with various program managers, limits in most services are there are a guide and form a logical understanding of what can be achieved. However, in most cases these can be raised through discussion with Microsoft.

The limits on VNET peering applies to two areas. The first is number of networks able to be peering to a single network (currently 50). The second is the number of routes able to be advertised when using ExpressRoute and VNET peering. Review the following Azure documentation article for more info on these limits: https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/#networking-limits.

Finally, it’s important to note that not every network is identical and requirements change from customer to customer. What is additionally as important is to implement consistent and proven architecture topologies that leverages on the knowledge and experience of others. Basically, stand on the shoulders of giants.