The new world: Azure Resource Manager
The Azure Resource Manager is the new methodology for deploying resources.
Since it
went into public preview, the Azure Service Management (ASM) deployment model
has been used to deploy services. In the Azure portal, services managed with
ASM are referred to as classic. In 2015, Microsoft introduced the
Resource Manager deployment model as a modern, more functional replacement for
ASM. The Resource Manager deployment model is recommended for all new Azure
workloads.
These
deployment models are often referred to as control planes because they
are used to control services, not just to deploy them. This is different from a
data plane, which manages the data used by a service.
Typically,
your running Azure infrastructure will contain many resources, but some of the
resources will be related to one another in some way, such as all being the
component services required to run a web application. For example, you might
have two VMs running the web application, using a database to store data, and
residing in the same virtual network. With Resource Manager, you deploy these
assets into the same resource group and manage and monitor them together. You
can deploy, update, or delete all of the resources in a resource group in one
operation.
In this
example, the resource group would contain the following:
VM1
VM2
Virtual network
Storage account
Azure
SQL Database
You can also create a template that precisely
defines all the Resource Manager resources in a deployment. You can then deploy
this Resource Manager template into a resource group as a single control-plane
operation, with Resource Manager in Azure ensuring that resources are deployed
correctly. After deployment, Resource Manager provides security, auditing, and
tagging features to help you manage your resources.
Why use
Resource Manager?
There are
several advantages to using Resource Manager. The deployment is faster because
resources can be deployed in parallel rather than sequentially as they are in
ASM. The Resource Manager model enables each service to have its own service
provider, and they can update it as needed independently of the other services.
Azure Storage has its own service provider, VMs have their own service
provider, and so on. With the ASM model, all services had to be updated at one
time, so if one service was finished and the rest were not, the one that was
ready had to wait on the others before it could be released. Here are some of
the other major advantages to the Resource Manager model:
Deployment using templates
You can create a reusable (JSON) template that can be used to deploy all of the
resources for a specific solution in one fell swoop. You no longer have to
create a VM in the portal, wait for it to finish, then create the next VM, and
so on.
You can
use the template to redeploy the same resources repeatedly. For example, you
may set up the resources
in
a test environment and find that it doesn’t fit your needs. You can delete the
resource group, which removes all of the resources for you, then tweak your
template and try again. If you only want to make changes to the resources
deployed, you can just change the template and deploy it again, and Resource
Manager will change the resources to conform to the new template.
You can take that template and easily re-create multiple versions of your infrastructure,
such as staging and production. You can parameterize fields such as the VM
name, network name, storage account name, etc., and load the template
repeatedly, using different parameters.
Resource Manager can identify dependencies in a template but allows you to
specify additional dependencies if necessary. For example, you wouldn’t want to
deploy a virtual machine before creating the storage account for the VHD files
that are used for the OS and data disks.
Security
You can use the new Role-Based Access Control (RBAC) to control
access to the resources in the group. For example, you can assign the Owner
role to a user, giving that user full administrative privileges to those
resources in the group but not to other resources in the subscription. Other
roles include Reader (you can read anything except secrets) and Contributor
(you can do most anything except add or revoke access).
Billing
To help organize
all of the resources in a subscription for billing purposes, you can assign
tags to each resource and then retrieve all of the billing information for a
specific tag.
For example, if one
department owns a web application and several related components, you can
assign the same tag to all of those resources. Then, you can retrieve the
billing for that department by retrieving the billing for that tag.
Note If you apply a tag to a resource group, the resources in the group
do not inherit that tag. You have to apply the tag to each
individual resource.