Jin on Code

Introduction

As a developer working with Azure, we need to understand the Azure Resource Manager, which provides a management layer for other APIs. We can distinguish it from an ARM template and understand its relation to Azure Resource Group, Resource Type, and Resource Provider.

Honestly, when I first started with Azure and began to understand Azure Resource Manager, I thought ARM and ARM templates were the same thing, but they’re not.

In this post, I’ll explain my understanding of Azure Resource Manager, Resource Group, Resource Provider, Resource Type, and Azure Resource Manager Template, as well as their differences.

So let’s get started.

What is Azure Resource Manager?

In my understanding, ARM serves as the management layer for all resources in Azure.

Moreover, it provides a unified API surface that the Azure Portal, Azure CLI, Azure PowerShell, and REST clients use.

Furthermore, ARM communicates with resource providers (e.g., Microsoft Compute, Microsoft Storage, etc.) to provision and manage resources, allowing us to think of ARM as the control tower of Azure.

What is a Resource Group?

A resource group enables you to organize resources logically and serves as a primary management boundary for Microsoft to deploy, monitor, and manage resources in Azure.

Two key takeaways from grouping resources: first, categorize them by the application life cycle (e.g., dev, test, qa, preprod, and prod); and second, organize them by organizational structure, such as specific departments or locations within an organization.

Additionally, the application life cycle keeps different environments isolated, making RBAC, cost tracking, and policies a bit easier (in my opinion).

Here are some things to keep in mind about resource groups.

• It is free; the resource group doesn’t cost anything and is not considered a resource itself.
• A resource group doesn’t serve as a communication barrier between other resource groups.
• A resource can only occupy one resource group and cannot be in multiple resource groups.

What are Resource Providers and Types?

About this concept, Resource Providers in Azure make specific categories of resources available, such as compute, storage, networking, or databases.

Imagine that it is a service that supplies resource types.

For example:

• Microsoft.Compute – it provides VMs, VM scale sets, disks, and snapshots
• Microsoft.Network – it provides VNets, NICs, and load balancers
• Microsoft.Storage – it provides storage accounts, blob containers, and file shares.

Now, resource type is the specific type of resources within the resource provider category.

For example, let’s say the resource provider is “Microsoft.Compute”, resource types could be “virtualMachines”, “disks”, “snapshots”, and “availabilitySets”.

The key thing to remember is that “Resource Provider” is a broad service category, while “Resource Type” is a specific kind of resource within the provider.

In contrast, the “Resource Instance” is your actual deployed thing in the cloud.

What is an ARM Template?

We won’t be tackling a lot of ARM templates here, but I’ll try to give at least a good background for us to understand them.

Fundamentally, an ARM template is a JSON file that describes the state of an infrastructure, because its primary purpose is to provision and configure resources in Azure.

Moreover, it is an Infrastructure as Code (IaC) that tells ARM what to build and manage.

A good analogy would be that an ARM template is the blueprint you submit to ARM, and ARM ensures the construction happens as specified.

Now that we have a good understanding of the difference between ARM and ARM templates, I would like to reiterate that Microsoft today recommends Bicep instead of writing raw ARM templates. However, under the hood, Bicep compiles down to ARM templates.

Characteristics of ARM Templates

Now that we have a good understanding of what an ARM template is, let’s discuss its characteristics here.

Idempotent

I still recall an interview where I struggled to explain a concept (I got a mental block). However, after learning from that experience, I can confidently say that if you run the same template multiple times, the result will be the same.

So, here’s how it works:

• When you deploy, ARM compares the template’s desired state vs the current state of resources.
• Then, if a resource exists and matches, no change at all.
• Then, if a resource exists but differs, ARM updates it to match it.
• Then again, if a resource doesn’t exist, ARM creates it.

Declarative

As you describe the end state, not steps, that’s why it is a declarative thing.

In imperative tools like Azure CLI, you instruct Azure on how to perform tasks step-by-step.

Thus, ARM templates say what it should look like.

Template Driven

As a JSON template file drives the template, you define things such as resources, parameters, variables, etc. Thus, it makes deployments reusable, automatable, and consistent.

Multi-service, Multi-region, Extensible

A single ARM template can deploy virtual machines, databases, storage accounts, networking, and other resources — enabling end-to-end solutions.

Templates are multi-region, since they can target resources across different regions within the same deployment.

Templates are also extensible, allowing you to nest or link templates for modularization. Additionally, ARM continuously evolves to support new resource types and services as they are released.

Summary

In this post, we have discussed ARM, Azure Resource Group, Azure Resource Provider, Azure Resource Type, and Azure templates.

I hope you learned a lot as I shared my knowledge and understanding here. Sometimes it’s easier to understand when I write things down in my head.

Once again, I hope you have enjoyed this article as I have enjoyed writing it.

Stay tuned for more. Until next time, happy programming!

Please don’t forget to bookmark, share, like, subscribe, and comment.

Cheers! And thank you!