Supporting a network in transition: Q&A blog post series with David Lef

In a series of blog posts, this being the fourth and last, David Lef, Principal Network Architect at Microsoft IT, chats with us about supporting a network as it transitions from a traditional infrastructure to a fully wireless cloud computing platform. Microsoft IT is responsible for supporting 900 locations and 220,000 users around the world. David is helping to define the evolution of the network topology to a cloud-based model in Azure that supports changing customer demands and modern application designs.

David Lef identifies the considerations and challenges of supporting a network environment as line of business applications move from an on-premises environment to the cloud using Azure.

Q: Can you explain your role and the environment you support?

A: My role at Microsoft is principal network architect with Microsoft IT. My team supports almost 900 sites around the world and the networking components that connect those sites, which are used by a combination of over 220,000 Microsoft employees and vendors that work on our behalf. Our network supports over 2,500 individual applications and business processes. We’re responsible for providing wired, wireless, and remote network access for the organization, implementing network security across our network (including our network edges), and connectivity to Microsoft Azure in the cloud. We support a large Azure tenancy using a single Azure Active Directory tenancy that syncs with our internal Windows Server Active Directory forests. We have several connections from our on-premises datacenters to Azure using ExpressRoute. Our Azure tenancy supports a huge breadth of Azure resources, some of which are public-facing and some that are hosted as apps and services internal to Microsoft, but hosted on the Azure platform. We currently host forty percent of our LOB apps using Azure, and that number is continually increasing.

Q: Can you give me a quick history of how this migration has happened and how the network teams have supported it?

A: It started with Azure platform as a service (PaaS), which we were using for internal and external app and service solutions. PaaS was the first primary component that was offered on Azure, so we naturally started there when developing solutions. Most of our early applications were hosted completely in Azure. The hybrid scenario wasn’t fully developed or supported, so we didn’t implement that in our solutions.

However, as Azure networking and infrastructure as a service (IaaS) components have been introduced and matured, we’ve had much more flexibility in how we implement Azure-based solutions and how those solutions interact with each other and our on-premises infrastructure.

We adopted a strategy for Azure migration that addressed the most logical migration scenarios first: basic web apps, any new solutions, and any solutions that were targeted for redesign. Next, we looked at some more challenging apps, such as those with large bandwidth or resource usage requirements, or those that had regulatory implications or significantly affected business-critical operations. Finally, the most difficult and costly apps are left, such as customized legacy solutions with code that is difficult to update.

The main enablers for hybrid line of business (LOB) apps were the addition of ExpressRoute, which gives any Azure tenant the ability to obtain a private, dedicated connection to Azure from their datacenter, and the maturation of Azure IaaS, which has enabled us to take on-premises infrastructure and migrate it directly to Azure-hosted virtual machines without having to modify the components of the infrastructure. We have also widely adopted software as a solution (SaaS) solutions, such as Office 365.

Our primary support channel has been to facilitate the connectivity required by hybrid solutions. A lot of the connectivity is on the back end through ExpressRoute and the configuration and management required to connect our datacenters to Azure, but we also manage networking within Azure. There are some important security and compliance considerations when cloud and on-premises mix, and we’ve been diligent in ensuring that our data and infrastructure in the cloud is as secure as it is in our datacenters. Most of our Azure apps and services are available from some Internet touch-point, so it’s important for us to delineate between front end and back end within our solutions. We don’t want our infrastructure living in IaaS exposed to the public Internet.

Q: Have the challenges changed through this journey?

A: They’re always changing! Change is the nature of the cloud, and that’s really the first challenge we faced: understanding that solutions, processes, and methods are fluid and changing in Azure. There is a continuous stream of features being offered and changed; some of them can be inconsequential to a solution, while others can be game changers.

We understand that there are many ways to connect to Azure, from the datacenter perspective and from the user perspective. As much as possible, we try to provide the freedom to allow our application owners in Azure the choice in how they connect their apps to the datacenter and to their customer.

As an organization, we’ve had to learn how to modify our strategies to focus on the cloud first. Hosting LOB apps in Azure is a fundamental change in how the apps are used and supported. We’ve been diligent in keeping support and communication channels open with our application owners and our customers, and it’s critical that they understand the nature of the cloud and what that means to them and their business. Our cloud-first, mobile-first strategy means that everything is directed to Azure first, and it’s a cultural change that has been spearheaded by our CEO, Satya Nadella, and cascaded down through the rest of the organization. There is an excellent article that highlights the continuing evolution of our cloud strategy.

From a technical perspective, we have a lot of tools and processes in place to help us manage our Azure resources in a way that matches the fluidity of the environment. The integration of Azure Resource Manager (ARM) has been critical to centralizing and standardizing solution management and configuration within Azure. Resource groups and ARM templates provide the functionality we need to configure things properly and ensure they stay configured properly through changes to app requirements or Azure functionality. It’s a constant challenge to maintain both the datacenter and Azure concurrently, both technically and logistically. Migrations to Azure are a constant stream, so the configuration of our datacenters and Azure environments are in constant flux. We have and will have a long legacy tail that will be carried around for a while, so we have to ensure that we’re providing and managing communications between Azure and our on-premises environments as proactively as possible, and educating our tenants and users on how to use both effectively.

Learn more

Other blog posts in this series:

• Supporting network architecture that enables modern work styles
• Engineering the move to cloud-based services
• Cloud-first, mobile-first: Microsoft moves to a fully wireless network

Learn more about how Microsoft IT is evolving its network architecture here.