A Deeper Look into Microsoft’s Azure Resource Manager

In the first part of this series, we discussed the evolution of Azure IaaS and role of Azure Resource Manager. The next installment of the series explains the key differences between Azure Service Management (ASM) and Azure Resource Management (ARM) models. We will also take a look at key concepts and terminology related to ARM.

ASM or ARM?

One of the key tenets of cloud, especially infrastructure services, is programmability. Almost every cloud provider exposes a set of APIs to manipulate the virtual infrastructure programmatically. Even before the Cloud Computing term became a buzzword, Amazon exposed APIs for storage and compute, which eventually became the core of AWS.

When Microsoft built Azure, developers could interact with the control plane through the Azure Service Management (ASM) API. Before officially supporting REST, ASM was exposed as a set of SOAP endpoints. Given the smaller set of services based on storage, compute, and application services, ASM was good enough for developers and third-party ISVs to talk to Azure. Eventually, as new services got added to Azure, the API footprint expanded proportionally. When the partner ecosystem started to develop tools for Microsoft’s public cloud platform, ASM became the core of Azure. Even today, ASM is extensively used by ISVs like CloudBerry Lab and Cerebrata. Microsoft started shipping language bindings, native SDKs, and command line tools that heavily relied on ASM.

Since ASM was the API facade for the first version of Azure IaaS, it suffered from the same limitations and constraints. Resource provisioning was not cohesive and offered no support for atomic deployments and rollbacks. Developers had to deal with a disjointed set of APIs to provision resources that logically belonged to the same workload.

The original Windows Azure Management Portal was built on top of ASM. With the introduction of Azure IaaS V2, Microsoft introduced a new portal that aligned with the ARM strategy. To differentiate these two interfaces, Microsoft started calling the old portal as the classic portal. Some of the resources such as VMs that are provisioned through the classic portal also derived the moniker of Classic VMs.

As we discussed earlier, Azure Resource Manager (ARM) is closely aligned with Microsoft’s roadmap for IaaS. Technically speaking, the resources provisioned through the ASM API cannot be accessed through the ARM endpoints. They are maintained separately to avoid possible conflict. The new Azure Portal has a separate link to access the VMs created via the classic portal and ASM. Even the CLI has to to be explicitly switched to ARM before accessing the V2 resources.

The new portal supports accessing both, the ASM and ARM resources. But some of the resources provisioned through ARM cannot be seen by the classic portal. Below screenshot shows how the new portal lets you access classic VMs, and Cloud Services created using ASM.

Azure New Portal Supporting both ASM and ARM Resources

The key difference between ASM and ARM is visible when you deploy a typical web application with a VM, storage account, public IP address, virtual network, and a load balancer. ASM treats each resource independently with no logical grouping.

ASM Deployment Model

The same application, when deployed through ARM, comes with a logical grouping of resources that can be managed as one unit.

ARM Deployment Model

Concepts and Terminology

Having understood the key differences between ASM and ARM, let’s now move to the core concepts of ARM.

The building blocks of Azure, such as compute, storage, and network act as resource providers. They are the blueprints for creating resources, which are the packaged and provisioned inside a resource group. A resource template is a declarative mechanism to define and configure the resources that belong to a resource group.

Resource Providers

A resource provider is a service that supplies the resources that can be deployed and managed through ARM. Each provider has its own APIs for accessing and manipulating the service. Microsoft is working towards adding ARM support for all Azure services. Resource providers are available through a unique namespace. For example, Microsoft.Compute represents the Virtual Machine resources. Resource providers have resource types that are accessible via the REST API. Microsoft.Storage provider has resource types of Blob, Queue, and Table. Similarly, Microsoft.Network exposes Load Balancers, Public IPs, Routes, Subnets, and Network Security Groups as resource types.

Any Azure service with a resource provider namespace can participate in ARM deployments. The resource types can be declared in the template. Refer to this section of Azure documentation for an updated list of resource providers.

The Compute, Storage, and Network resource providers fundamentally differ between ASM and ARM. Since the operations are different, they need to be treated differently.

Resource Groups

According to the official definition, a resource group is a container that holds related resources for an application. The resource group may include all of the resources for an application, or only those resources that are logically grouped together.

All the resources that belong to the same resource group share a common lifecycle. They are deployed, updated, and deleted together. If a resource such as an SQL Database instance needs to be independent, it has to be in a separate resource group. Resources that belong to different groups can be linked. For example, a resource group with an SQL Database resource can be linked to multiple groups containing different web applications.

It’s also important to know that a resource can exist in one and only one resource group at a time. Though resources can be moved from one group to another, they cannot be shared. A resource group may contain resources that span multiple regions. They are still treated as one logical unit.

Resource Templates

Resource templates are most important components of ARM that provides a declarative way of defining the deployment and configuration of an application. They are JSON documents which can repeatedly be deployed with the same consistent results. ARM templates are less error prone when compared to manual or scripted deployments.

Resource templates contain the definition of the infrastructure, the configuration of individual resources, and the way an application is published to that infrastructure. The order in which the resources are defined is not important as Azure can determine the correct sequence of resource provisioning. This relieves IT admins and DevOps teams from worrying about the infrastructure dependencies.

Large deployments tend to include multiple varieties of resources that may turn the template too big to manage. To avoid the complexity, resource templates can be linked to each other.  To deploy a particular solution, administrators can create a master template that links all of the required templates. Each template can be independently managed and maintained.

ARM templates can be integrated with existing provisioning and configuration management tools such as Chef, Puppet, Ansible, and PowerShell DSC. This feature makes ARM play well with existing DevOps tools.

Finally, since ARM template is just a JSON file, they can be maintained in the same version control system as the application. DevOps teams can easily integrate ARM with existing Infrastructure-as-Code strategies.

In the next part of this series, we will author an ARM template to deploy LAMP stack on Microsoft Azure. Stay tuned!

Feature image via Pixabay.