Writing an Azure Resource Provider:

 

Introduction: Azure offers a control plane for all resources that can be deployed to the cloud and services take advantage of them both for themselves and their customers. While Azure Functions allow extensions via new resources, Azure Resource provider and ARM APIs provide extensions via existing resources. This eliminates the need to have new processes introduced around new resources and is a significant win for reusability and user convenience. New and existing resources are not the only way to write extensions, there are other options such as writing it in the Azure Store or via other control planes such as container orchestration frameworks and third-party platforms. This article focuses on the ARM API.

Description:  The {resource-provider}/{resource-type} addition to the inventory in Azure is required for tasks such as deployment because it retrieves information that can assist with the orchestration of steps for deployment. As the resources mature and the SKUs evolve, the resource APIs are revision-ed and the client must keep up.

When the deployment actions need to be expanded, revisioning the API is not sufficient. New capabilities must be added to the resource. One way to do this is to write an extension resource that modifies another resource such as to assign a role to a resource. In this case, the role assignment is an extension resource type.

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. Bicep is succint so it provides a further incentive and there is a playground to try it: Bicep Playground 0.4.1-ge2387595c9 (windows.net).