How Azure Resource Manager Helps You Coordinate Effectively and Deploy Interdependent Entities
Azure Resource Manager (ARM) is a new way to deploy and manage the services in your application. You can interact with ARM from Azure Management Portal, REST API, PowerShell, and Azure CLI. Azure Resource Manager enables users to work with resources such as virtual machines and databases in a solution as a single group. This model is often referred to as ARM or v2. The other way of deployment is referred to as classic or Azure Service Management (ASM) or v1. Microsoft recommends using the Resource Manager Deployment model instead of the classic system, as well as re-deploying existing resources through ARM if possible. Today, most services support ARM.
Resource Groups Combine Resources into a Coherent Application
Azure Resource Manager offers developers an easy way to create and manage a set of related resources in an orderly, predictable, and consistent fashion.
A Resource Group is a logical container which holds a set of related resources which you want to manage as a single unit. You can create a single resource group for all resources in your application, including storage, multiple virtual machines, NICs, IP Addresses, load balancers, subnet, and Network Security group. Or, if you want to have a network as a basic unit and then be able to deploy multiple applications on top of it, you could have one resource group which contains a subnet, Network Security Group, and IP addresses, and another resource group with storage and multiple virtual machines. Also, if you are not able to decide at first on how to organize your resources into resource groups, don’t worry. Most resources may be moved into other resource groups.
How ARM Provides a Consistent Deployment Mechanism
ARM helps you define your deployment in a declarative JSON template. Using these templates, you can deploy and consistently redeploy your application. Resource Manager Templates enable us to specify resource dependencies, which help ensure that resources are deployed in the correct order. ARM template deployments are incremental, thereby ensuring that ARM does not re-provision the resource if it is in the same state as defined in the template.
Resource Tagging Provides an Efficient Way to Organize Your Entities
ARM supports organizing the resources by applying tags. A tag is a key-value, which can have up to 512 characters for the key and 256 characters for the value. Each resource can have up to 15 tags. We can define the taxonomy for tags and make use of tagging for various scenarios. Tag taxonomy is subscription wide, and resources from all resource groups share the same taxonomy. The typical use case is to organize resources for billing or management by specifying the cost center, environment etc. Also, I have seen deployments where tags are used for on-call alias, specifying an owner for the resource (in some scenarios, we wanted to define a single point of contact on the resource – independent of RBAC & permissions).
Critical Access Control Concepts in ARM
Role-based access control (RBAC) is natively integrated into ARM. In the classic model, we only had two levels of access across all subscriptions (service administrator and co-administrator). ARM comes with many built-in roles. Built-in roles include general roles like Owner, Contributor, and Reader as well as service specific roles like SQL DB Contributor, SQL Security Manager, SQL Server Contributor etc. Each role specifies a set of operations that are allowed (called actions) or denied (called not actions) on specific resources. RBAC is by default a deny and explicit allow system. We can assign roles to users, groups or services at subscription, resource group, or resource levels.
Additionally, ARM allows you to configure a lock for write or delete operations on a subscription, resource group or resource to prevent accidental update or deletion of critical resources.
How and Why to Develop Custom Resource Management Policies
ARM enables us to define custom policies for managing our resources. Policies can be applied at the subscription, resource group, or resource level. Unlike RBAC, policies function by default as an allow and explicit deny system. Policies work together with RBAC – users must be authenticated through RBAC before the policy evaluation kick-start. The typical use case for using policies is to enforce specific tags for resources, to restrict certain resources to be created only inthe specific region, enforcing naming convention of resources, and so on.
Next Steps
Now that you have a concrete understanding of Azure Resource Manager, it’s time to set up a project of your very own. To help you develop proficiency with Azure, we offer a wide range of Azure courses, including Introduction to Azure Resource Manager. This course covers the following topics:
- Best Practices for JSON Templates,
- Deploying ARM JSON Templates,
- Access Control in Azure Resource Manager,
- JSON Template Tooling,
- And a huge variety of demos to help get you started.
Sign up for your free 7-day trial today and start learning Azure right away!
