On a recent customer engagement, one of the questions that came up was “Should we use Classic mode or should we use the new Resource Manager?”. The guidance from Microsoft is to deploy all new workloads into Azure ARM, however after scratching the surface, it’s not quite so cut and dry.
Some Background
Azure is a platform that is currently undergoing a significant transformation and as a result, confusingly, there are two deployment models supported by Azure public cloud: Classic and Azure Resource Manager (ARM). The reason I say it’s confusing is because individual Azure resource features or behaviors can be different across the two models, or only exist in one model or the other.
There are two Portals in use today:
- Classic Azure Portal: If you’ve been using Azure for a while, you’ve used this portal. It is used to create and configure older Azure resources that support the classic deployment model. You cannot use it to create or configure resources that only support Resource Manager.
- ‘New’ Azure Portal: Recently out of Preview, if you’re using a newer Azure resource, you’ve probably used this portal. It can be used to create and configure some Azure resources. You’ll eventually be able to create and configure all Azure resources with it. For some resources that support both deployment models, this portal can be used to create and configure a resource using either deployment model.
How you create, configure, and manage your Azure resources is different between these two models. For example, load balancing traffic across virtual machines created with the Classic deployment model is implicit because virtual machines are members of an Azure Cloud Service, and load is automatically balanced across virtual machines within a cloud service. Virtual machines created using Resource Manager are not members of a cloud service, and a separate Azure Load Balancer resource must be explicitly created to load balance traffic across multiple virtual machines.
In Classic mode, each resource provisioned in Azure is a single management unit. Although Azure resources are created in a cloud container, when it comes to managing resources in a cloud container, you must manage all of the resources individually. The classic mode does not allow grouping of resources, which makes managing Azure resources difficult.
When you interact with Classic mode resources from a command line such as Azure PowerShell, you are using Azure Service Management API calls (ASM). ASM is a traditional way of accessing Azure resources. Both the Classic portal and Azure PowerShell use ASM API calls to manage Azure resources. It is important to note that if the Classic portal has been used to create or manage Azure resources, you can only work with Classic resources.
On the other hand, ARM plays an important role in managing resources as a single unit as it allows you to deploy Azure resources in groups called Resource Groups.
The new Azure portal allows the ability to work with both Classic and ARM Resources and when you interact with ARM using command-line tools such as Azure PowerShell, you are using ARM API calls.
ARM provides the following 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
So which one should I use?
Since both modes are viable options at this point, it is necessary to pay careful attention to the features that each offer and your specific requirements. ARM cannot simply be assumed to be the best fit as it simply may not meet all of your or your customer’s needs.
Unfortunately, some functionality still lies in the old portal but Microsoft is rapidly bringing this functionality across. In the past, it was common to have to go to both portals to build up a set of resources and services in Azure, however the “new” portal is being positioned as the single portal to create and manage services in both worlds.
The pace of newly deployed features and updates into ARM is hard to keep up with and it appears that Microsoft have removed the compatibility matrix they used to publish.
A good place to start learning about the benefits of the new portal is the General Availability Announcement along with Azure Resource Manager Overview and Azure Resource Manager vs. Classic Deployment: Understand deployment models and the state of your resources
While I love Azure, this simply was very poorly thought out by Microsoft. They should not have put ARM into production until they had developed the capacity to migrate or sync all data from the “classic” portal to the “new” portal. I will do as little as possible in the new portal until they fix this as I am not about to attempt to migrate my entire production infrastructure without a simple solution to do so. If they attempt to force us to manually migrate to the new portal I will “migrate” to AWS instead. I hope that it doesn’t come to that.
More details can be found here https://blog.kloud.com.au/2016/04/05/azure-classic-vs-azure-resource-manager/
Azure originally provided only the classic deployment model. In this model, each resource existed independently; there was no way to group related resources together. Instead, you had to manually track which resources made up your solution or application, and remember to manage them in a coordinated approach. To deploy a solution, you had to either create each resource individually through the classic portal or create a script that deployed all the resources in the correct order. To delete a solution, you had to delete each resource individually. You could not easily apply and update access control policies for related resources. Finally, you could not apply tags to resources to label them with terms that help you monitor your resources and manage billing.
In 2014, Azure introduced Resource Manager, which added the concept of a resource group. A resource group is a container for resources that share a common lifecycle