Adopting Microsoft Azure Resource Manager internally at Microsoft

Nov 2, 2022   |  

Microsoft Digital technical storiesThe work we do here at Microsoft is powered by the cloud, something that wouldn’t be possible without adopting Microsoft Azure Resource Manager.

We’re the Microsoft Digital Employee Experience (MDEE) team, and our efforts to power, protect, and transform the company is powered by Microsoft Azure. As such, we are continually looking for ways to deploy and manage our Azure resources in the most efficient way possible. One of the ways we’re doing that is with Microsoft Azure Resource Manager, which we’re using to enable agile cloud implementation and management in the midst of our digital transformation. It’s also helping us establish standard practices throughout our Azure environment.

Making Microsoft Azure the first choice for IT infrastructure

The cloud-first, mobile-first culture at Microsoft is designed to give our business groups the most effective IT environment possible. For our IT teams, this means being able to create that environment quickly, to the required scale, and in a cost-effective manner. Microsoft has championed a move to the cloud because it gives us the infrastructure we need to power the next generation of business applications. It also elevates collaboration and productivity, enabling our employees to be more successful.

Microsoft Azure is at the core of our cloud infrastructure. We are continually moving applications to the cloud, and Azure is the first choice for new IT solutions that we implement. We currently support the largest public, cloud-based corporate IT infrastructure in the world using Azure. Our Azure environment includes:

  • More than 1,700 active Microsoft Azure subscriptions.
  • More than 1,100 cloud-based applications.
  • More than 15,000 Microsoft Azure virtual machines.
  • More than 18 billion Microsoft Azure Active Directory authentications per week.
  • More than 30 trillion objects stored on Microsoft Azure.

Our business runs on Microsoft Azure, and we are dedicated to increasing our footprint in the cloud, migrating our on-premises to Azure. The sheer volume of infrastructure in Azure requires a management solution and approach that allows our IT teams to deploy and manage Azure resources in an efficient and timely manner.

Understanding Microsoft Azure Resource Manager

Microsoft Azure Resource Manager provides the framework for the resources used to create solutions in Microsoft Azure. It gives you a way to deploy and manage Azure resources as a solution. For example, for an application that is used to track sales records your solution might consist of several Azure virtual machines connected by Microsoft Azure Virtual Networks, and using a variety of other Azure resources.

The Microsoft Azure Resource Manager model involves several important components:

  • Resource groups. A resource group is a container that holds related resources for an application. A resource group can include all of your resources for an application or only those resources that are logically grouped together. You can decide how you want to allocate resources to resource groups based on what makes the most sense for your organization.
  • Role-based access control. You can add users to predefined platform and resource-specific roles and apply those roles to a subscription, resource group, or resource to limit access. For example, you can use the predefined role known as SQL DB Contributor that lets people manage databases, but not database servers or security policies. You add people in your organization that need this type of access to the SQL DB Contributor role and apply the role to the subscription, resource group, or resource.
  • Tags. You can use tags to categorize resources according to your managing or billing requirements. You might want to use tags when you have a complex collection of resource groups and resources that you need to visualize in the way that makes the most sense to you. For example, you can tag resources that serve a similar role in your organization or that belong to the same department. Without tags, people in your organization can create multiple resources that may be very difficult to identify and manage later. For example, you may want to delete all of the resources for a particular project, but if those resources were not tagged for the project, you will have to manually find them.
  • Templates. Templates define the deployment and configuration of your application. Templates provide a declarative way to define deployment. By using a template, you can repeatedly deploy your application throughout the app lifecycle and have confidence that your resources are deployed in a consistent state.
  • Policy. You create policy definitions that describe the actions or resources that are specifically denied in Azure. You assign those policy definitions at the desired scope, such as the subscription, resource group, or an individual resource. For example, you can use policy to control where resources are allowed to be created. Or you might want to control access to the resources by allowing only certain types of resources to be provisioned.

Using these components, the Azure Resource Manager model provides several advantages:

  • You can deploy, manage, and monitor all of the resources for your solution as a group, rather than individually handling these resources.
  • You can repeatedly deploy your solution throughout the development lifecycle and have confidence that your resources are deployed in a consistent state.
  • You can use declarative templates to define your deployment.
  • You can define the dependencies between resources so that they are deployed in the correct order.
  • You can apply access control to all services in your resource group because role-based access control (RBAC) is natively integrated into the management platform.
  • You can apply tags to resources to logically organize all of the resources in your subscription.
  • You can clarify billing for your organization by viewing the rolled-up costs for the entire group or for a group of resources that share the same tag.

Enabling agile cloud infrastructure

Our implementation of Microsoft Azure Resource Manager started with new implementations of Microsoft Azure solutions. We adopted Azure Resource Manager as the default model for all new solutions. New solutions transitioned smoothly to Azure Resource Manager, and most of our existing Azure infrastructure remained in the Microsoft Azure Service Management model. However, there were cases where we needed a solution to access resources from both models, and we also had to reconcile the way we monitored and managed resources from each model to provide a monitoring and management environment that is as unified as possible.

Using templates to simplify deployment and management

Microsoft Azure Resource Manager templates give you the opportunity to create standardized deployment and management processes that are reusable within the Azure Resource Manager environment. We used templates heavily throughout the Azure Resource Manager deployment process.

To store and deploy the templates, we used a GIT repository that publishes automatically to a GitHub repository, which is available externally. We used nested or linked templates that require access to a publicly accessible URI—in this case, GitHub—specifically, raw.githubusercontent.com. These repositories gave us the ability to store our templates centrally, to establish standards, and to provide a location where people could start their own deployments. By using these repositories, people were able to clone their own instance of the repository to their local machine for customization, modification, and testing before publishing changes. GitHub also gave us the ability to take advantage of our internal community contributions to the Azure Resource Manager template ecosystem. The two repositories that we used were:

  • Internal Microsoft Azure Resource Manager Repository. This is where we stored our standard, compliant, and parallel Azure Resource Manager templates that we support. These templates allowed us to specialize deployment for scenarios such as domain-joined virtual machines, standardize configuration of drives and storage, and create and implement common Azure tags on deployed resources.
  • Community Microsoft Azure Resource Manager Repository. This repository was open for internal Microsoft use, but we did not validate or check compliance. This repository allowed people to create their own templates and share them with the rest of the organization so that innovation and Azure Resource Manager development could be shared. This repository does not publish to GitHub.

Key Takeaways

Here are our best practices we learned implementing Microsoft Azure Resource Manager internally here at Microsoft:

  • We established several design and implementation practices that help us to create a consistent and uniform Microsoft Azure Resource Manager environment. With these best practices, we realized significant efficiencies in the deployment and management of Azure Resource Manager–based resources.
  • We established that Microsoft Azure subscriptions would be created for each service and named accordingly. This created a very detailed level of control over Azure resources. At Microsoft, a service is defined as a primary business function. There are currently more than 200 services, which often contain multiple applications and resource groups.
  • We established a services naming convention to provide consistency and continuity. In addition to the name of the service, our naming convention included using the company prefix of “MSFT” and a numeric suffix to allow multiple subscriptions for the same service if it ever becomes necessary. For example:
    • MSFT Customer Relationship Management 1
    • MSFT International Tax 1
    • MSFT Commercial Business Reporting 2
    • MSFT Network and Infrastructure Mgmt IT Solutions 3
  • We recommended that applications have their own dedicated resource group. Resource groups are created within each subscription, and each resource group contains objects or applications that share a similar lifecycle. Resource groups can have specific RBACs assigned—each resource group will have different users assigned different permissions. Virtual machines in a solution must be members of a single resource group, and there will often be multiple virtual machines in each resource group.
  • Use RBAC to establish permissions for groups. In our Microsoft Azure environment, RBAC is designed to establish role permissions for resource groups or subscriptions. We used our Active Directory environment and synchronized with groups in RBAC on Azure. We used the built-in roles to define permission levels and then used those roles to establish permissions for our internal RBAC groups.
    • Reader: Can view all Microsoft Azure components except secrets, but can’t make changes.
    • Contributor: Can manage everything except user access.
    • User Access Administrator: Can manage user access to Azure resources.
  • Using tags provides easy management across many scenarios. Tags were helpful in grouping resources for scenarios outside of the scope of typical application maintenance. We reserved a certain number of tags so that resources could be easily identified by change management database users. We also used tags extensively for tracking compliance and billing, which was useful when compliance or billing-related resources spanned multiple applications or resource groups.
  • Templates were an immense change to the way we created and managed Microsoft Azure resources. By using the JavaScript Object Notation (JSON) templates in Azure Resource Manager, we deployed and manage an entire solution—including virtual machines, virtual networks, and associated resources. By using templates, we defined how and when Azure resources were created or changed. We were also able to create dependencies and implementation requirements for complex applications with large, complex sets of Azure resources. Templates are hosted on GitHub, so people can innovate and develop templates.

Related links