Azure Management Models: ASM vs ARM

Notes from articles around the web:

* Azure Resource Manager and Azure Service Managment "Classic" deployment models are not completely compatible with each other. 

* To simplify the deployment and management of resources, Microsoft recommends that you use Resource Manager for new resources, and, if possible, re-deploy existing resources through Resource Manager.

The Resource Manager version of Azure PowerShell commands have the format Verb-AzureRmNoun whereas the Service Management version of Azure PowerShell commands have the format Verb-AzureNoun

Resource Manager added the concept of the resource group. Every resource you create through Resource Manager exists within a resource group. 

The Resource Manager deployment model provide several benefits:
- Deploy, manage and monitor Azure resources as a group
Deploy resources repeatedly
Supports creating templates. Templates can be created to include a set of resources to be deployed as part of a cloud solution
Allows you to define dependencies between resources so they are deployed in the correct order
Ability to apply RBAC policies to all resources in a Resource Group
Ability to specify "tags" to resources for programmatic purposes

Virtual machines deployed with the Resource Manager deployment model must be included in a virtual network whereas it is not so in the classic deployment model

Resource Manager is supported in all regions, but the resources you deploy might not be supported in all regions.

Both the Classic portal and Azure PowerShell version before 1.0 use ASM API calls to manage Azure resources.

If you use the Classic portal to create or manage Azure resources, you can only work with Classic resources whereas the new Azure portal at https://portal.azure.com allows the ability to work with both Classic and ARM Resources.
Slide from the Pluralsight course Managing Azure IaaS with PowerShell 

The following table describes changes in how Compute, Network, and Storage resource providers interact:

Item Classic Resource Manager
Cloud Service for Virtual Machines Cloud Service was a container for holding the virtual machines that required Availability from the platform and Load Balancing. Cloud Service is no longer an object required for creating a Virtual Machine using the new model.
Virtual Networks A virtual network is optional for the virtual machine. If included, the virtual network cannot be deployed with Resource Manager. Virtual machine requires a virtual network that has been deployed with Resource Manager.
Storage Accounts The virtual machine requires a storage account that stores the VHDs for the operating system, temporary, and additional data disks. The virtual machine requires a storage account to store its disks in blob storage.
Availability Sets Availability to the platform was indicated by configuring the same “AvailabilitySetName” on the Virtual Machines. The maximum count of fault domains was 2. Availability Set is a resource exposed by Microsoft.Compute Provider. Virtual Machines that require high availability must be included in the Availability Set. The maximum count of fault domains is now 3.
Affinity Groups Affinity Groups were required for creating Virtual Networks. However, with the introduction of Regional Virtual Networks, that was not required anymore. To simplify, the Affinity Groups concept doesn’t exist in the APIs exposed through Azure Resource Manager.
Load Balancing Creation of a Cloud Service provides an implicit load balancer for the Virtual Machines deployed. The Load Balancer is a resource exposed by the Microsoft.Network provider. The primary network interface of the Virtual Machines that needs to be load balanced should be referencing the load balancer. Load Balancers can be internal or external. A load balancer instance references the backend pool of IP addresses that include the NIC of a virtual machine (optional) and references a load balancer public or private IP address (optional). Read more.
Virtual IP Address Cloud Services get a default VIP (Virtual IP Address) when a VM is added to a cloud service. The Virtual IP Address is the address associated with the implicit load balancer. Public IP address is a resource exposed by the Microsoft.Network provider. Public IP Address can be Static (Reserved) or Dynamic. Dynamic Public IPs can be assigned to a Load Balancer. Public IPs can be secured using Security Groups.
Reserved IP Address You can reserve an IP Address in Azure and associate it with a Cloud Service to ensure that the IP Address is sticky. Public IP Address can be created in “Static” mode and it offers the same capability as a “Reserved IP Address”. Static Public IPs can only be assigned to a Load balancer right now.
Public IP Address (PIP) per VM Public IP Addresses can also be associated to a VM directly. Public IP address is a resource exposed by the Microsoft.Network provider. Public IP Address can be Static (Reserved) or Dynamic. However, only dynamic Public IPs can be assigned to a Network Interface to get a Public IP per VM right now.
Endpoints Input Endpoints needed to be configured on a Virtual Machine to be open up connectivity for certain ports. One of the common modes of connecting to virtual machines done by setting up input endpoints. Inbound NAT Rules can be configured on Load Balancers to achieve the same capability of enabling endpoints on specific ports for connecting to the VMs.
DNS Name A cloud service would get an implicit globally unique DNS Name. For example: mycoffeeshop.cloudapp.net. DNS Names are optional parameters that can be specified on a Public IP Address resource. The FQDN is in the following format - <domainlabel>.<region>.cloudapp.azure.com.
Network Interfaces Primary and Secondary Network Interface and its properties were defined as network configuration of a Virtual machine. Network Interface is a resource exposed by Microsoft.Network Provider. The lifecycle of the Network Interface is not tied to a Virtual Machine. It references the virtual machine's assigned IP address (required), the subnet of the virtual network for the virtual machine (required), and to a Network Security Group (optional).

Related:
Deep Dive into Azure Resource Manager Scenarios and Patterns
Azure Resource Manager vs. classic deployment

Comments