A $100-billion Fortune 200 consumer packaged goods company recently partnered with CapTech to commercialize Microsoft Azure's Platform as a Service (PaaS) as an enterprise service offering. This blog is the fifth in a ten-part series of blogs. The purpose of this post is to highlight the design considerations and implementation activities involved with establishing MPLS connectivity between the client's network and the cloud. It is intended for anyone interested in gaining insight into the major bodies of work and considerations involved in commercializing cloud services for large enterprises.

Recommended Bodies of Work

The next couple of posts in this series are going to focus on some of the recommended bodies of work for commercializing the cloud at your organization. Below is a diagram that illustrates a high level and comprehensive view of the bodies of work with their relationships and dependencies. In the remainder of this post we will explore what's involved in establishing MPLS connectivity highlighted in green.

Workstreams

MPLS Connectivity - Express Route

Before we dive into what is involved in establishing MPLS connectivity, we should first define the terminology. Here's a quick summary of the terminology that we will use in this post. Multiprotocol Label Switching (MPLS) is the name of the technology although it can be referred to differently depending on your enterprise network service provider. For example, AT&T refers to it as NetBond. Microsoft refers to it as Express Route. For the sake of consistency, we will use Express Route going forward.

Express Route is a dedicated private connection between your enterprise's on-premise data center and MSFT's Azure data center. It is required for hybrid design patterns described in the pre-requisites. The connectivity is illustrated below:

Private Connection

Express Route provides increased reliability and speed, higher security, and lower latencies. This effort will require expertise from your Cloud, Security, and Network Architects as well as the enterprise's network service provider and other 3rd party IT infrastructure vendors/partners. Because of the Request for Services (RFS) process for procurement and implementation with other vendors/partners, this effort may also be a long pole in the tent. It is strongly recommended that you start this work stream very early in the commercialization process.

Establishing Express Route

Before establishing Express Route, there are some questions you should answer. Some of the questions the enterprise may want to consider include, but are not limited to:

  • Does the current on-premise data center require additional hardware before implementation?
  • Which Microsoft Azure data centers (e.g. East vs. West) will be used?
  • Will forced tunneling and public peering be enabled with Express Route?
  • Will redundancy be required between Microsoft Azure data center and an alternate on-premise data center?

After answering these questions, the enterprise can begin implementing Express Route. Below is a summary of the implementation activities that will be executed in close partnership with the enterprise's network service provider:

  • Obtain an Azure subscription from Microsoft.
  • Work with the network service provider, such as AT&T or Verizon to sign up for virtual network connection to extend the enterprise virtual private network (VPN) to Microsoft's cloud service.
  • Design the virtual network connection, VPN, Firewalls etc.
  • Create the Express Route circuit suing PowerShell cmdlet, and produce the Express Route service key required for later use.
  • Create the virtual network connection. This will require the VPN name and the virtual network connection name.
  • Create the virtual network connection VLAN. This will require /29 address space, the virtual connection name, and the Express Route service key.
  • Propagate the route, and link the VNET to Express Route through the Azure portal and PowerShell cmdlet. Turn down any existing site-to-site VPN gateways. This will require /28 address space for network gateway.

Conclusion

This fifth post in the ten-part series described establishing MPLS connectivity to commercialize Azure with this Fortune 200 CPG client. These were the questions we had to answer and the steps we had to follow to establish the connectivity. This process should be very similar regardless of who your network service provider is.

The entire series:

Commercializing Azure Part 9 - Transitioning to Support Commercializing Azure Part 10 - Summary of Benefits

In the next post we are going to talk about designing the solution architecture.