What Is Azure Resource Manager?

What Is Azure Resource Manager?

Azure Resource Manager (ARM) is an Azure service that you can use as a code paradigm to control and deploy assets using an infrastructure. It allows you to use a number of features to provide, change, and uninstall services, including access controls, tags, and locks.

There is some unique terminology you should be aware of when using Azure Resource Manager. Words that are most common include:

Resource: an asset that is manageable. it include  Virtual machines (VMs), virtual networks, databases, mobile applications, and storage accounts for subscriber. Tags, subscriptions, resource classes, or management groups can also refer to resources.

Resource group: A container that contains an Azure solution’s associated resources. There are resources in the resource community that you want to handle as a group. Based on what makes the most sense for your company, you determine which resources belong in a resource category.

Resource provider: an individual Azure service in which you can generate resources. For example Microsoft Disk or Microsoft Compute,

Template of the Resource Manager: a file that specifies how classes, subscriptions or tenants should be deployed with resources. This file is specified in the JavaScript Notation of Objects (JSON).

Declarative syntax : syntax that allows you to say “Here is what I intend to create” without having to write the programming command sequence in order to create it. An example of declarative syntax is the template Resource Manager. In the code, you describe the infrastructure properties to deploy to Azure. See Description of template deployment.

The following image illustrates the role played by the Resource Manager in managing requests from Azure.

PowerShell, Azure CLI, REST APIs, and client SDKs also have all the features that are available on the Azure portal. Within 180 days of the initial release, features initially released via APIs will be reflected in the portal.

Azure resource groups

A fundamental feature of the Azure platform is resource groups. For resources deployed on Azure, a resource category is a logical container. In an Azure subscription, these tools are everything you make, such as VMs, instances of Azure Application Gateway, and instances of Azure Cosmos DB. All resources must be in a group of resources, and only a member of a single group of resources may be a resource.

Most resources may be shared between resource groups with those programs that have unique restrictions or conditions to be transported. Resource classes are not nest able. You need a resource category for it to be put in before any resource can be provisioned.

Logical grouping

To help manage and coordinate your Azure resources, resource groups exist. You can provide the resources you build in Azure with order and structure by putting resources of similar use, form, or location in a resource category. The aspect you are most interested in here is logical grouping, because there is a lot of disorder among our properties.

Life cycle

If you uninstall a resource group, all the resources it contains will be removed as well. In non-production environments, grouping resources by life cycle may be useful, where you might try an experiment and then dispose of it. To eliminate a collection of resources all at once, resource groups make it simple.

Authorisations

Resource groups also provide space for the implementation of RBAC (Role-Based Access Control) permissions. You can ease management and restrict access by adding RBAC permissions to a resource group to allow only what are required.

The advantages of Resource Manager 

• Manage the infrastructure, rather than scripts, by declarative templates.
• Deploy, handle, and monitor all the resources as a group for your solution, rather than personally managing these resources.
• Throughout the implementation lifecycle, redeploy your solution and have faith that your assets are deployed in a consistent state.
• Define the resource dependencies such that they are deployed in the correct order.
• Apply access control to all services since RBAC is built natively into the platform for management.
• Apply resource tags to logically organize all of your subscription services.
• Clarify the billing of your company by viewing expenses for a community of services sharing the same tag.

Comprehend spectrum or Understand scope

Four levels of reach are offered by Azure: management groups, subscriptions, groups of resources, and resources. An example of these layers is shown in the following picture.

At any of these levels of scope, you apply management settings. How broadly the setting is applied defines the level you choose. Settings from higher levels are inherited by lower levels. When you apply a subscription policy, for example, the policy extends to all of the resource groups and services in your subscription. When you apply a resource group policy, it extends the policy to the resource group and all of its services. Another resource group, though, doesn’t have the policy assignment.

Resource groups

When identifying your resource group, there are several significant factors to consider:

• The same lifecycle should be shared by all resources in your resource community. Together, you deploy, upgrade and uninstall them. In a separate deployment period, if one resource, such as a server, has to exist, it should be in another resource category.
• In only one resource group, each resource will exist.

• At any time, you can add or delete a resource to a resource category.
• You may transfer a resource to another group from one resource group. See Transferring Resources to a New Resource Group or Subscription for more information.
• The properties in a resource group can be found in regions other than the resource group.
• You need to include a place for that group of resources when building a resource group. You may be asking, “Why does a resource group need a location? And, if the resources can have different locations than the resource group, why does the resource group location matter at all?” The resource group stores resource metadata. If you specify a resource group location, you specify where the metadata is stored. You can need to make sure your data is stored in a certain area for enforcement purposes.
• If the area of the resource group is temporarily inaccessible, the resources in the resource group cannot be updated because the metadata is unavailable. The tools will still operate as planned in other areas, but you can’t upgrade them. See Developing Reliable Azure Applications for more detail about creating reliable applications.
• You may use a resource group to monitor the extent of access for administrative acts. You may delegate Azure Policies, Azure responsibilities, or resource locks to control a resource group.
• For a resource category, you can add tags. The resources do not inherit certain tags in the resource community.

Azure Resource Manager Resiliency

The operation of the Azure Resource Manager is built for durability and continuous accessibility. In the REST API, Resource Manager and control plane operations (requests sent to management.azure.com) are:

• Distributed between regions. Certain services are regional.
• Distributed in areas that have several Availability Zones across Availability Zones (as well as regions).
• Not reliant on a logical single data center.
• Never taken down for the activities of maintenance.
• This resilience is relevant to programs receiving requests from the Resource Manager. For instance, this resiliency benefits Key Vault.