This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the use of Multitenancy and Azure Resource Manager in multitenant solutions. 

Azure Resource Management is the core management service for Azure. Every resource in Azure is created, managed, and eventually deleted through the resource manager.  A multitenant application may work with Resource Manager to dynamically provision resources for each tenant. There are also many features of Resource Manager that support Multitenancy. 

Infrastructure can be described as code. Resource Manager provides and honors resources templates as the language for describing infrastructure and the state that it must achieve.  

The Azure Resource Manager maintains tags, RBAC, ARM Templates, Locks, policies and activity logs for the resources and the create, update, delete of the resources are exposed via the CLI, PowerShell, HTTP request, and Azure Portal. It is the deployment and management service for Azure. Most services from Azure register ARM templates to provision their resources. The uniform format of this template serves well for the management layer.  
Azure templates are like formula, we can use it for dedicated purposes.  For example, we can have a quick start template for Linux Virtual machine. There is a growing community of 350 unique templates, 300 unique contributors and over 4500 visitors each day. A custom resource provider can extend the ARM API to include internal and external resources. It enables custom scenarios on top of existing Azure workflows. The ARM Templates can be customized for control and effect.  The contract between Azure and an endpoint is defined through a new resource named as the Microsoft.CustomProviders/resourceProviders. This implies there are three parts: the custom resource provider, endpoints and the custom resources. A custom resource is comprised of three fields: name, routingType and endpoint. ResourceTypes describe new custom resources. Supported http methods are PUT, DELETE and GET. Actions can be added to a custom resource or across all resources via Azure. The equivalent CRUD operation via PowerShell includes the New-AzCustomProvider cmdlet and the association with an endpoint is created via the New-AzCustomProviderAssociation.  
  

Just like with any actions surrounding Azure resources via the Azure Resource Manager templates, a resource must be added to the extension resource template at a proper scope such as resource group, subscription, management group and tenant. For example, resource createRgLock ‘Microsoft.Authorization/locks@2016-09-01' can be declared to add a lock at the resource group level. A lock prevents actions that can usually be taken on a resource with the provision for overrides. This is sometimes necessary when authoring policies surrounding resources.  

A ‘scope’ property allows an extension resource to target another resource. It specifies the resource to which this extension applies. It is a root property of the extension resource. An extension resource is for custom actions around the resource that are not generally available from the resource. It is different from a child resource.  

A child resource exists only within the context of another resource. Each parent resource can accept only certain resource types as child resource types. For example, where we can refer to resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets/extensions@2021-04-01' only within the context of virtual machine scale sets and not without VMSS. The hierarchy of parent-child resource types are already registered before they can be used. An extension resource can extend the capabilities of another resource.  

Resources and their extensions can be written only in Bicep and ARM templates. Bicep provides more concise syntax and improved type safety, but they compile to ARM templates which is the de facto standard to declare and use Azure resources and supported by the unified Azure Resource Manager. Bicep is a new domain-specific language that was recently developed for authoring ARM templates by using an easier syntax. You can use either template format for your ARM templates and resource deployments. Bicep is typically used for deployments to Azure. It is a new deployment-specific language that was recently developed. Either or both JSON and Bicep can be used to author ARM templates and while JSON is ubiquitous, Bicep can only be used with Resource Manager Templates. In fact, Bicep has tooling that converts Bicep templates into standard Json Templates for ARM Resources by a process called transpilation. This conversion happens automatically but it can also be manually invoked.  

The Azure Resource Manager not only offers a standardized ARM template, but also provides a consistent management layer. When users send a request from any of the Azure Tools, APIs or SDKs, the resource manager receives the request. It authenticates and authorizes the request. The resource manager sends the request to the Azure service. With this framework, the Azure Resource manager can manage the infrastructure through declarative templates, manage and monitor all the resources for a solution, redeploy a solution throughout the development lifecycle and with a consistent state, define the dependencies between the resources so that they are deployed in the correct order, apply access control to all services because Azure role-based access control is natively integrated into the management platform, apply tags to resources to organize them, and group resources by the same tag to help with billing and cost management.