In this article, as part of our IT Infrastructure as Code series, we're going to explore the three fundamental building blocks for managing your resources on Azure:

Azure Resource Manager
Azure Resource Provider
ARM Templates

Note: ARM is an acronym for Azure Resource Manager.

Azure Resource Manager

The Azure Resource Manager is the official deployment and management service for Microsoft Azure. It provides a layer that enables you to manage (create, update, delete) different resources in your Azure account.

Benefits

Let's take a look at some of the benefits that this service offers:

Declarative templates instead of scripts: Consistent state amongst deployed resources is guaranteed as your app infrastructure and dependencies are defined in a single declarative template
Improved management and organization of resources: No more piece-by-piece deployments of your app and manually stitching them together. Resources with a common lifecycle are grouped in a resource group that can be deployed or deleted in a single action. You can see which resources are linked by a dependency and/or categorize resources by tags for management tasks (e.g., billing)
Authorization: ARM offers control access to resources. You control who in your organization can perform actions on any resource. Permissions are managed by defining roles and adding users (or groups of users) to those roles. ARM logs all user actions so you can audit those actions

Basic Terminology

In the previous section, I mentioned something called a resource group. Before we continue, let's explain some of the most basic terminology you'll need to understand when working with the ARM:

Resource: Manageable items such as virtual machines, storage accounts, web apps, databases, etc., are regarded as resources. As strange as it may seem, resource groups are also treated as resources.
Resource group: As the name implies, a resource group is a container that holds related resources for an Azure solution. For example, you usually include all your resources related to a single application deployment in a resource group. This might include an app service, static web app, app service plan, SQL server & database, etc.
Declarative syntax: It defines "what" we want to happen; we don't care how it happens. ARM templates and Bicep files are examples of declarative syntax.
Bicep file: A file for declaratively deploying Azure resources.

Management Layer

ARM is the middleman between different access routes to Azure services and the actual resources.

Here's an image that better illustrates this:

Diagram that shows the role of Azure Resource Manager in handling Azure requests.

No matter how you try to access Azure services & resources, whether through the Azure web portal, the Azure API, CLI, or SDKs, the Resource Manager intercepts all requests. It authenticates and authorizes the request before forwarding it to the appropriate Azure service.

Because all requests are handled through the same API, you see consistent results in all the different tools.

Scope

Azure provides four levels of scope:

Management groups
Subscriptions
Resource groups
Resources

The most common scopes used are subscriptions and resource groups.

We can deploy templates to tenants, management groups, subscriptions, or resource groups.

It's the first time we mentioned tenants, so I'll quickly explain what tenants are:

An Azure AD (Active Directory) tenant is a reserved Azure AD service instance that an organization receives and owns once it signs up for a Microsoft cloud service such as Azure or Microsoft 365.
Azure Active Directory, now known as Microsoft Entra ID, is a cloud-based identity and access management service. It provides single sign-on, multifactor authentication, and more.

These concepts are out of the scope of this article, but we might hear them again in future articles, so I've linked some extra resources at the end so you can check them out.

Azure Resource Provider

An Azure resource provider is a service that supplies Azure resources. It's a set of REST operations that enable functionality for a specific Azure service.

Example per the Microsoft documentation:

The Key Vault service consists of a resource provider named Microsoft.KeyVault. The resource provider defines REST operations for managing vaults, secrets, keys, and certificates.

The resource provider defines the Azure resources you can deploy to your account.

The good thing is that a resource type's name is standardized and follows this format:

{resource-provider}/{resource-type}.

The resource type for a key vault is Microsoft.KeyVault/vaults.

Of course, you don't have to remember different resource types off the top of your head. Microsoft provides documentation for all types, and you can easily look them up!

Why are they important?

Resource providers are important because we use the resource provider types to register our resources in our declarative language (ARM templates or Bicep). That's how we tell Azure what resources we want to deploy.

It's important to note that before we can use a resource provider, we must ensure our Azure subscription is registered for the one we want to use. Tip: register a resource provider only when you're ready to use it. Registering unnecessary resource providers may result in unrecognized apps appearing in your Microsoft Entra ID tenant.

Some resource providers are registered by default. Other resource providers are automatically registered when you take specific actions.

When you carry out specific actions, other resource providers are registered automatically. Usually, the resource provider is already registered for you when you create a resource using the Azure web portal. The resource providers specified in an ARM template or Bicep file are immediately registered when deployed.

There are situations when a templated resource needs supporting resources not included in the template. Resources for monitoring or security are frequent examples. Those resource providers must be manually registered.

ARM Templates

If you made it this far, give yourself a pat on the back! That was boring; now we're getting into the exciting stuff.

ARM templates are normal JSON files that define one or more resources to deploy to a resource group, subscription, management group, or tenant. These templates can deploy resources consistently and repeatedly without configuration drift. That's how we implement infrastructure as code for our Azure solutions!

How does an ARM Template file look like?

Within the template file, we can write additional template expressions that extend the capabilities of JSON. These expressions make use of the functions provided by the Resource Manager.

Each ARM template file has the following sections:

Parameters: Provide values during deployment that allow the same template to be used with different environments.
Variables: Define values that are reused in your templates. They can be constructed from parameter values.
User-defined Functions: Create customized functions that simplify your template.
Resources: Specify the resources to deploy.
Outputs: Return values from the deployed resources.

Here's an example ARM template that tells Azure RM to create a Storage Account:

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2022-09-01",
    "name": "mystorageaccount",
    "location": "centralus",
    "sku": {
      "name": "Standard_LRS"
    },
    "kind": "StorageV2"
  },
]

When a template is deployed, the Resource Manager intercepts the request and converts this template into REST API operations. The example above would translate to the following operations:

PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/mystorageaccount?api-version=2022-09-01
REQUEST BODY
{
  "location": "centralus",
  "sku": {
    "name": "Standard_LRS"
  },
  "kind": "StorageV2",
  "properties": {}
}

This request is then sent to the appropriate resource provider. In this example, that's Microsoft.Storage provider.

Why should you use ARM Templates?

Here are some benefits to convince you to use ARM templates:

Declarative syntax
Repeatable results
Orchestration
Modularity
Extensibility
Testing
CI/CD integration

Why you shouldn't write ARM Templates.

Alright, you saw the benefits, but now I will convince you not to write ARM templates! Pretty ironic, but hear me out!

Hello Bicep!

Bicep is a new domain-specific language (DSL) that uses declarative syntax—created explicitly for deploying Azure resources.

It's the recommended way to deploy your Azure resources because it offers the same capabilities as ARM templates. However, the syntax is much easier to use, and the developer experience is way better!

I won't go any deeper; the next article in this series will be about Bicep💪😉.

Conclusion

In this article, we explored the Azure Resource Manager, Resource Provider, and ARM Templates and scratched the surface of Microsoft's new DSL Bicep.

If you enjoyed reading this article, make sure to follow us for more on the same topic in the coming weeks!

Managing Azure Services & Resources