Azure Resource Manager

Azure Resource Manager (ARM) 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 the registration of resource providers to subscriptions and regions; it makes the resource types available to resource groups; it makes the resource and resource APIs accessible to the portal and other clients; and it authenticates access to resources. It also enables features such as tagging, authentication, Role-Based Access Control (RBAC), resource locking, and policy enforcement for subscriptions and its resource groups. It provides the same deployment and management experience, whether through a portal or client-based tools such as PowerShell or a command-line interface.

The ARM architecture

The architecture of ARM and its components are as shown in the following diagram. As we can see in the following figure, Azure Subscription comprises multiple resource groups. Each resource group contains resource instances that are created from resource types available in the resource provider:

Azure Resource Manager architecture

Limitations of Azure Service Manager (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. Some of the limitations to ASM are mentioned here:

• Parallelism: 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: Resources in ASM are provisioned and managed in isolation from each other; there is no relation between ASM resources. Grouping services and resources or configuring them together is not possible.
• Cloud services: Cloud services are the unit of deployment in ASM. They are reliant on affinity groups and not scalable due to their 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 over 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 are not consistent between resources.

ARM advantages

ARM provides distinct advantages and benefits over ASM, which are as follows:

• Grouping: ARM allows grouping of resources together in a logical container. These resources can be managed together and go through a common life cycle as a group. This makes it easier to identify related and dependent resources.
• Common life cycle: Resources in a group have the same life cycle. 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 also 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 (IAC). 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 advanced features, such as security, monitoring, auditing, and tagging, 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 updating of resources within and across resource groups.

ARM concepts

With ARM, everything in Azure is a resource. Examples of resources are virtual machines, network interfaces, public IP addresses, storage accounts, and virtual networks. 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 that are responsible for providing resource types through ARM. The top-level concept in ARM is 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 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 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, you need to check whether the required resource provider is available in each region. If it is available, the user can explicitly register in the subscription.

Resource types

These are an actual resource specification defining their public API interface and implementation. They implement 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 of their schema and public API interface. The version names are based on the dates that they are released 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 and yet belong to the same resource group. Resource groups provide additional services to all the resources within it. Resource groups provide metadata services, such as tagging, which enables the categorization of resources, policy-based management of resources, RBAC, protection of resources from accidental deletion or updates, and more. As mentioned before, they have a security boundary, and users that don't have 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 OOP 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.

ARM features

The following are some of the major features provided by ARM:

• 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 for 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 individual, 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 out-of-the-box roles. It provides system roles, such as owner, contributor, and reader. It also provides resource-based roles, such as SQL DB contributor and virtual machine contributor. 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 the 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. 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 relate to departments, resource usage, location, projects, or any other criteria deemed fit from a cost, usage, billing, or 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 is policies. Custom policies can be created to control access to resources. Policies are defined conventions and rules and must be adhered to while interacting with resources and resource groups. The policy definition contains an 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 a JSON-based policy definition language for defining policies. Some examples of policy definition are that it must tag every provisioned resource, and 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 of child resources. Locks applied at the subscription level lock every resource group and the resources within it.
• Multi-region: Azure provides multiple regions for provisioning and hosting 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 configuration, no matter the number of times it is executed.
• Extensible: ARM architecture provides an extensible architecture to allow the creating and plugging of new resource providers and resource types into the platform.