Azure Resource Manager

ARM is the successor of ASM. Although both platforms are operational and available as of writing this chapter, Microsoft is moving toward using ARM as a platform for all future deployments.

ARM and ASM

ASM has inherent constraints and some of the major ones are discussed here:

• ASM deployments are slow and blocking. Operations are blocked if an earlier operation is already in progress.
• Parallelism is a challenge in ASM. It is not possible to execute multiple transactions successfully in parallel. The operations in ASM are linear and executed one after another. Either there are parallel operation errors or they will get blocked.
• Resources in ASM are provisioned and managed in isolation from each other. There is no relation between ASM resources. Grouping of services and resources, configuring them together is not possible.
• Cloud services are the unit of deployment in ASM. They are reliant on affinity groups and not scalable due to its design and architecture.
• Granular and discreet roles and permissions cannot be assigned to resources in ASM. Users are either service administrators or co-administrators in the subscription. They either get full control on resources or do not have access to them at all.
• ASM provides no deployment support. Deployments are either manual or you will need to resort to writing procedural scripts in PowerShell or .NET.
• ASM APIs were not consistent between resources.

ARM advantages

ARM provides distinct advantages and benefits over ASM. They are:

• Grouping: ARM allows grouping of resources together in a logical container. These resources can be managed together and undergo a common lifecycle as a group. This makes it easier to identify related and dependent resources.
• Common lifecycle: Resources in a group have the same lifecycle. These resources can evolve and be managed together as a unit.
• Role-Based Access Control: Granular roles and permissions can be assigned to resources providing discreet access to users. Users can have only those rights that are assigned to them.
• Deployment support: ARM provides deployment support in terms of templates enabling DevOps and Infrastructure as Code. The deployments are faster, consistent, and predictable.
• Superior technology: Cost and billing of resources can be managed as a unit. Each resource group can provide their usage and cost information.
• Manageability: ARM provides advance features such as security, monitoring, auditing, and tagging features for better manageability of resources. Resources can be queried based on tags. Tags also provide cost and billing information for resources tagged similarly.
• Migration: Easier migration and update of resources within, as well as across, resource groups.

ARM concepts

With ARM, everything in Azure is a resource. Examples of resources are virtual machine, network interfaces, public IP address, storage accounts, virtual networks, and more. ARM is based on concepts related to resource providers and resource consumers. Azure provides resources and services through multiple resource providers that are consumed and deployed in groups.

Resource providers

These are services responsible for providing resource types through Azure Resource Manager. The top level concept in ARM are resource providers. These providers are containers for resource types. Resource types are grouped into resource providers. They are responsible for deploying and managing the resources. For example, a virtual machine resource type is provided by a resource provider called Microsoft.Compute Namespace. The REST API operations are versioned in order to distinguish between them. The version naming is based on the dates on which they are released by Microsoft. It is necessary that a related resource provider is available to a subscription in order to deploy a resource. Not all resource providers are available to a subscription out of the box. If a resource is not available in the subscription, one has to check if the required resource provider is available in a given region. If that is available, the user can explicitly register in the subscription.

Resource types

These are an actual resource specification defining its public API interface and implementation. It implements the working and operations supported by the resource. Similar to resource providers, resource types also evolve over time with regard to their internal implementation and have multiple versions for its schema and public API interface. The version names are based on dates that they are released on by Microsoft as a preview or General Availability (GA). The resource types become available to a subscription after a resource provider is registered to it. Also, not every resource type is available in every Azure region. The availability of a resource is dependent on the availability and registration of a resource provider in an Azure region and must support the API version needed for provisioning it.

Resource groups

Resource groups are a unit of deployment in ARM. They are containers grouping multiple resource instances in a security and management boundary. A resource group is uniquely named in a subscription. Resources can be provisioned on different Azure regions yet belong to the same resource group. It provides additional services to all resources within it. Resource groups provide metadata services like tagging which enables categorization of resources, policy-based management of resources, Role-Based Access Control, protection of resources from accidental deletion or updates, and more. As mentioned before, they have a security boundary and users not having access to a resource group cannot access resources contained within it. Every resource instance needs to be part of a resource group or else it cannot be deployed.

Resource and resource instances

Resources are created from resource types and should be unique within a resource group. The uniqueness is defined by the name of the resource and its type together. In OOPS parlance, resource instances can be referred to as objects while resource types can be referred to as a class. The services are consumed through the operations supported and implemented by resource instances. They define properties that should be configured before usage. Some are mandatory properties while others are optional. They inherit the security and access configuration from its parent resource group. These inherited permissions and role assignments can be overridden for each resource. A resource can be locked in such a way that some of its operations can be blocked and not made available to roles, users, and groups even though they have access to it. They can be tagged for easy discoverability and manageability.

Azure Resource Manager

Azure Resource Manager is the technology platform and orchestration service from Microsoft that ties up all components discussed earlier. It brings Azure resource providers, resources, and resource groups together to form a cohesive cloud platform. It helps in registration of resource providers to subscriptions and regions, it makes the resource types available to resource groups, makes the resource and resource APIs accessible to the portal and other clients, and authenticates access to resources. It also enables features like tagging, authentication, Role-Based Access Control, resource locking, and policy enforcement for subscriptions and its resource groups. It provides the same deployment and management experience whether through portal or client-based tools like PowerShell or a command-line interface.

Azure Resource Manager architecture

Figure 1 shows the architecture of Azure Resource Manager and its components. As shown in the figure, Azure Subscription comprises of multiple resource groups. Each resource group contains resource instances that are created from resource types available in the resource provider.

Figure 1: Azure Resource Manager architecture

Azure Resource Manager features

The following are some of the major features provided by Azure Resource Manager:

Role-Based Access Control

Azure Active Directory (AAD) authenticates users to provide access to subscriptions, resource groups, and resources. ARM implements OAuth and RBAC within the platform, enabling authorization and access control to resources, resource groups, and subscriptions based on roles assigned to a user or group. A permission defines access to operations on a resource. These permissions could allow or deny access to the resource. A role definition is a collection of these permissions. Roles map AAD users and groups to the permissions. Roles are subsequently assigned to a scope which can be an inpidual, collection of resources, resource group, or subscription. The AAD identities (users, groups and service principles) added to a role gain access to the resource according to permissions defined in the role. ARM provides multiple roles out-of-the-box. It provides system roles like Owner, Contributor, Reader, and more. It also provides resource-based roles like SQL DB contributor, virtual machine contributor, and more. ARM allows the creation of custom roles.

Tags

Tags are name value pairs that add additional information and metadata to resources. Both resources and resource groups can be tagged with multiple tags. Tags help in categorization of resources for better discoverability and manageability. Resources can be quickly searched and identified easily. Billing and cost information can be fetched for resources that have the same tags applied. While this feature is provided by ARM, an IT administrator defines its usage and taxonomy with regard to resources and resource groups. Taxonomy and tags for example, can be defined based on departments, resource usage, location, projects, or any other criteria deemed fit from a cost, usage, billing, and search perspective. These tags can then be applied to resources. Tags defined at the resource group level are not inherited by its resources.

Policies

Another security feature provided by ARM are policies. Custom policies can be created to control access to the resources. Policies are defined conventions and rules and must be adhered to while interacting with resources and resource groups. The policy definition contains explicit denial of actions on resources or access to resources. By default, every access is allowed if it is not mentioned in the policy definition. These policy definitions are assigned to resource, resource group, and subscriptions scope. It is important to note that these policies are not replacements or substitutes for RBAC. In fact, they complement and work together with RBAC. Policies are evaluated after a user is authenticated by AAD and authorized by the RBAC service. ARM provides JSON-based policy definition language for defining policies. Some of the examples of policy definition are that it must tag every provisioned resource or resources can only be provisioned to specific Azure regions.

Locks

Subscriptions, resource groups, and resources can be locked to prevent accidental deletion and updates by an authenticated user. Locks applied at higher levels flow downstream to child resources. Locks applied at subscription level, lock every resource group and resources within it.

Multi-region

Azure provides multiple regions for the provisioning and hosting of resources. ARM allows resources to be provisioned at different locations and yet reside within the same resource group. A resource group can contain resources from different regions.

Idempotent

This feature ensures predictability, standardization, and consistency in resource deployment by ensuring that every deployment will result in the same state of resources and their configuration no matter the number of times it is executed.

Extensible

ARM architecture provides extensible architecture to allow creation and plugging of newer resource providers and resource types into the platform.