and more instances, more instances can be patched simultaneously based on
groupings of role instances called upgrade domains. When patching occurs, all
instances within an upgrade domain are brought down and updated at the same time,
and then when the update is complete, the next upgrade domain is updated, and so on.
Availability sets also distribute instances between fault domains, which can be
thought of as racks in an Azure datacenter to ensure that if there is a rack-level
problem, the entire service is not taken down.
Previously Azure leveraged the Azure Service Manager (ASM) to manage resources
that Azure IaaS was built on, which is why VMs were created in Cloud Services.
However, many limitations existed, such as a lack of parallel action execution, which
limited the ability to provision services quickly, no role-based action control to finely
assign permissions, and limited ability to deploy services in an idempotent fashion.
Today Azure has moved to Azure Resource Manager (ARM), which has been
redesigned to address the previous limitations of ASM and enhance its capabilities.
Key features of ARM are as follows:
IaaS no longer utilizes cloud services.
Massive parallelism enables hundreds of resources to be created in the same time
as one with ASM.
Resources live in a Resource Group.
Role-based access control is available at a resource and Resource Group level.
Perform JSON-based deployment of workloads.While a resource must exist in one and only one Resource Group, this does not stop
resources in different Resource Groups from working together. For example, a VM in
one Resource Group can use a virtual network that is in a different Resource Group.
Resource Groups can be heterogeneous or homogeneous. In a heterogeneous
example, you would place all resources that share a common life cycle—such as a
storage account, NIC, virtual machine, Azure SQL Database, and a web app—that offer
a particular service in a common Resource Group to enable easy visibility, billing, and
management. A homogeneous example is a Resource Group for all storage accounts,
another for virtual networks, and so on. There is no right or wrong approach. If your
organization separates management into different groups for storage, networking, and
computing, then having separate Resource Groups for each type of resource would aid
in the delegation of management. If instead each project has its own resources that
share a common life cycle, using a heterogeneous approach will fit closest with how
you actually leverage Azure.