Q. What are key differences with IaaS v2 enabled through Azure Resource Manager?
A. Azure Resource Manager (ARM) heralds big changes to every aspect of Azure, including Infrastructure as a Service (IaaS), which can simply be thought of as VMs in the cloud.
The adoption of ARM for IaaS moves the solution to IaaS v2 and introduces capabilities such as:
- Rich template based deployment including dependencies between objects in the template which are expressed in the template
- Simplification of deployment
- Role-based Access Control (RBAC)
- Tagging of resources for identification of resources and visibility during billing
- Parallel deployment of VMs
One way to identify some of the key differences between IaaS v1 and IaaS v2 deployments is to look at how VM is deployed in each.
The figure below shows a typical IaaS v1 VM deployment with multiple VMs in a single cloud service.
In this deployment, the VMs exist within a cloud service and each VM has a Dynamic IP (DIP) that enables VMs within the same cloud service to communicate. Notice also:
- The DIP is routable only within the cloud service and the address pool usually comes from RFC 1918 and 100. ranges, with the administrator having no control over the IP scheme used.
- An Azure DNS is used which allows name resolution between the VMs in the same cloud service.
- The Cloud Service has Virtual IP (VIP) which is an Internet routable IP address. Through this VIP endpoints are created which point to specific ports on VMs within the cloud service.
- The Cloud Service also has a DNS name and provides load-balancing and auto-scale services for the VMs in the cloud service.
A Virtual Network could optionally be used. This enables a custom defined IP scheme to be used with alternate custom DNS configuration, communication between VMs in different cloud services and connectivity to on-premises as shown.
IaaS v2 using ARM changes this. Here's what's different:
- It removes the use of the Cloud Service (PaaS still uses Cloud Services). Instead all VMs must now be part of a Virtual Network and live within a Resource Group, which can also contain other types of resource such as storage.
- Because there is no cloud service, the functions of the cloud service move to other constructs. VMs can have their own Internet routable IP address that is not shared using an instance-level public IP address (PIP) giving a VM direct Internet connectivity (note PIPs can also be used with IaaS v1).
Alternately, it is possible to create a load balancer resource and assign a VIP to the load balancer which points to network adapters assigned to VMs. This new architecture is shown below.
If you think of equating IaaS v1 to IaaS v2 I think the following:
- The DNS name that was previously assigned to the Cloud Service now is configured as part of a VIP assigned to a load balancer.
- The container for expressing availability is now directly the Availability Set.
- Load balancers are now a discrete object that is referenced when creating virtual network adapters and assigning to a VM.
- The VIP is now assigned to a load balancer (or use a PIP directly with a VM).
- Endpoints are now NAT rules on the load balancer.
- VMs are always placed in Virtual Networks.
- Certain discrete resources must be provisioned before the VM is created such as network adapters.
The order of performing actions in IaaS v2 is:
- Create a Resource Group (which can contain resources from all over the world).
- Create or ensure there is an existing ARM (v2) storage account and virtual network to be used by the new VM. You cannot use non-ARM virtual networks or storage accounts with an ARM based VM.
- Create a network adapter object which must be placed in a virtual network (the virtual network does not have to be in the same resource group as the VMs).
- Create a VM and attach the network adapter object to it.
- Add either a PIP to the network adapter or create a load balancer and assign a VIP then create NAT rules to enable Internet access to the VM services. Typically if you have a single VM needing to offer services you can assign a PIP but for larger scale use a network load balancer with NAT rules.
Remember that while PowerShell can still be used, the best way to create VMs with ARM is to use the JSON based templates. There is a rich repository of sample templates available that can be used as the basis for your own templates.