Back in July, when Microsoft declared Azure Virtual WAN to be a Public Preview, the international (MPLS) connectivity market sighed in awe…

 

After Microsofts’ bold earlier moves into other markets, like:

  • Storage  with Storage Spaces, Storage Spaces Direct, Hyper-V Replica and Storage Replica

  • Identity with Azure Active Directory (B2B, B2C, Enterprise Apps and DS)

  • Mobile Device Management with SCCM and Intune

Are they Microsofts’ next target?

In their goal to provide more and more end-to-end services to their customers, I think the development of this Software Defined Wide Area Network (SD-WAN) offering is just a logical step and not necessarily a targeted attack on connectivity providers. It fits perfectly in their strategy to provide services to their customers near the last mile of their location, what traditionally was the realm of the connectivity providers or – brokers.

Just one warning for we dig in deeper, Azure Virtual WAN is currently a managed Public Preview. To use Virtual WAN, you must Enroll in the Preview.This Public Preview is provided without a service level agreement and should not be used for production workloads. My small advice here would be to create a separate subscription for this test, since some of these Azure Virtual WAN resources can be kind of difficult to get rid off in your subscription. 

Now what is Azure Virtual Wan?

The Azure Virtual WAN service provides potentially optimised, automated and global scale branch connectivity. This connection optimisation can be done through partners in this service. Currently “only” 2 partners are active, Riverbed and Citrix.

We expect more partners to be supported when this service reaches the GA status, as shown in the picture below.

When the service is configured, the Azure WAN built-in dashboard provides instant troubleshooting insights that gives you an easy way to view large-scale Site-to-Site connectivity.

When your device is connected, the data flows from your (branch-) office, into your VPN device (or traffic shaper), through your ISP, into the Microsoft Datacenter (Region A), into another Microsoft Datacenter (Region B), towards the Microsoft Edge, which is connected to an ISP, terminated on your branch VPN device, towards a server, service or workstation present locally.

So, if this is something driven by and with partners, where does Microsoft come into play? Well, you might of heard about their massively connected global network, extended by Microsofts’ Edge sites and Points-of-Presence (PoPs). Traffic from your offices enters Microsoft’s network at the Microsoft edge site closest to a given branch office. Once your traffic is in the Microsoft global network, it terminates in a virtual hub. An Azure Virtual WAN is composed of multiple virtual hubs. You can create your hubs in different Azure regions.

Hubs?

As always with new services, we also get some new distinctive words to accompany them. For Azure Virtual Wan, the building blocks (or resources) are called as follows:

  • virtualWAN:  a virtual overlay of your Azure network and is a collection of multiple resources. It contains links to all your virtual hubs that you would like to have within the virtual WAN.
  • Site: your VPN device and its settings. By working with a Virtual WAN partner, you presumably get a built-in solution to automatically export this information to Azure.
  • Hub:  a Microsoft-managed virtual network. The hub contains various service endpoints to enable connectivity from your on-premises network (vpnsite).
  • Hub virtual network connection: used to connect the hub seamlessly to your virtual network. At this time, you can only connect to virtual networks that are within the same hub region.

Isn’t this just a fancy VPN connection?

That kind of depends on your definition of “fancy”. First, a hub gateway is not the same as a virtual network gateway that you use for ExpressRoute and VPN Gateway. When using Virtual WAN, you don’t create a Site-to-Site connection from your on-premises site directly to your VNet. Instead, you create a Site-to-Site connection to the hub. The traffic always goes through the hub gateway. This means that your VNets do not need their own virtual network gateway. Virtual WAN lets your VNets take advantage of scaling easily through the virtual hub and the virtual hub gateway.

Conclusion

So the question we started this blog with, “will all connection providers go out of business when Microsoft launches this feature”?

I’m afraid not just yet, because for now, we still need connectivity to land this tunnel onto. For example a 4G internet connection from a building site, or a plain DSL connection from your latest outlet-store. On top of that connection we can put this new connectivity service from Microsoft, which seems like a no-brainer when you’re an international company and your backend is already running in Azure. This however could put quite a dent into the revenue model of some connectivity providers out there.

To be honest, a lot of things within this solution (when you’re a little network-savvy) could be configured already today with a multi-site-to site VPN. The value add here is in the automation of the routing, insights in (inter-regional) connectivity, and traffic shaping by partners. Currently, in the preview you can create a test environment with Azure Virtual Wan with a maximum of 100 connected locations per hub/region and a throughput (on the back-end) of 1Gbps. If you do sign-up for the preview, don’t forget to provide feedback, so Microsoft can improve the service further.

That’s all for now, did any questions come up when you were reading this? Do you have some feedback for me? Leave a comment below or drop me an email.

Until the next time, keep it cloudy!

Bert Wolters
http://www.twitter.com/BertWolters

Leave a Reply