Right since the time when the cloud technology started becoming affordable and easily available, users are happy to deploy the resources in cloud with the help of cloud giants such as Microsoft’s Azure, Amazon’s AWS, and Google to name a few. Microsoft’s Azure has two different management frameworks for deploying and managing resources. Let’s understand and compare these two frameworks.
Infrastructure as a Service (IaaS) involves hosting of hardware, software, servers, storage, and related components. IaaS platforms are highly scalable and hence are best for unexpectedly changing workloads. IaaS includes automating the administrative tasks, dynamic scaling, desktop virtualization, and policy based services. Many complex applications running on IaaS require a combination of resources, for example, Virtual network, Virtual Machine, Storage Account, and a Network Interface. To help their users with this combination, Azure first introduced Azure Service Management (ASM) API. Being a REST based API, users can manage deployments, hosted services, and storage accounts. ASM deployments include viewing, creating, deleting, modifying configuration settings, and more such functions.
ASM – now known as Classic – is a service that helps users to have programmatic access to many of the functions available through Management portal. In this management service, cloud service acts as a container for resource deployments. Load Balancers, with a public IP, are tightly coupled to the cloud service to have internet access to the VMs in the cloud service and balance the traffic coming to VMs. Though this is good, still there are some major concerns that users face.
Major concerns with ASM are:
- ASM has resource specific APIs as there is no facility to create a resource group. Hence, it is not possible to manage all the resources in a single coordinated operation. To deploy, start, configure, or manage every resource individually is time consuming and tedious.
- ASM lacks control over access of resources. Any user who has access to the cloud service has access to all the resources. In such case, users with role that is not specific to the resource also get access to that resource, which is not safe.
- ASM uses XML templates, but these are difficult to maintain as compared to JSON templates.
- Dynamic IP addresses of VMs are routable only within the cloud service. Hence, VMs in two different Cloud Services, though part of same subscription, cannot communicate directly. Those Cloud Services need to be brought under same virtual network.
- Since every resource has to be provisioned independently, the dependencies are not taken care of automatically. For example, before provisioning a VM, a storage account needs to be created, because VM needs that for storing its components. Such needs are not managed automatically.
- As there is no grouping facility, user, on its own, has to manage relationship amongst resources to determine the total cost for its web application. This process is not easy.
- If automated provisioning fails while provisioning dependent resources then it needs to be handled manually which is not the right thing to do.
Considering these drawbacks, Azure has come up with new management framework Azure Resource Manager (ARM). It helps the users deploy the related and interdependent components of a single unit as a group. It follows the concept of resource group. Resources can be grouped logically. Though ARM is not a complete replacement for ASM as of now, it definitely addresses the issues and makes the resources management simpler.
Benefits of ARM are:
- User can spun up a JSON template which includes instructions for creating all the resources and build a resource group (example: VM, storage, database, and network) in real time. This facilitates deploying all the resources in a single operation.
- Managing JSON templates is simpler than managing XML templates.
- Since a resource group is treated as a single unit of management, it becomes easier to identify the costs for entire resource group and manage accounting.
- ARM provides Role Based Access Control (RBAC) facility to secure the resources. Hence, user with role specific to the resource has access only to that resource.
- Since the deployment is template based, ARM identifies the already existing resources and provisions only those that are missing.
- All the VMs are part of a Virtual Network .Thus all VMs can communicate with each other.
- ARM provisions those resources simultaneously that are not interdependent. This care is taken automatically by its management framework.
- Cloud Services is not needed as the Availability Set itself is the container to indicate the availability of resources.
- Virtual IP is needed only when users create load balancer to manage traffic coming to the virtual machines.
- There are three Fault domains in ARM. This helps in having more VMs in an Availability Set. Since, fault domains are racks in which VMs are provisioned, if one rack fails due to network or power issue, VMs in other racks continue to provide services.
- Network adapter object is individually placed in the Virtual Network and then attached to VM. This helps because, if the VM, to which it is attached fails, the same network adapter object could be attached to another VM.
- Resource Manager helps in tagging the resources. The tags have key/value pairs that identify the resources with the properties that user defines. Resources from same category if tagged with same tag, then those resources could be viewed at the same time even if these resources lie in different resource groups.
- ARM takes care of dependencies of the resources in the resource group. It identifies the dependent resources and provisions the resources that need to be provisioned prior to the dependent resource.
ARM has started supporting most of the services, but some are yet unsupported. Users, for their existing deployments on ASM, can continue to use ASM and consider ARM for their new deployments.