Azure v1 vs. Azure v2: Is it time to move house?

Spoiler Alert: For those of you too busy to read this post the answer is an imminent YES.

Azure is the midst of a paradigm shift as it evolves from Azure Service Manager (ASM) to Azure Resource Manager (ARM) – so-called Azure v1 and Azure v2.

Many organisations have looked to Azure (and other cloud providers) as the solution to a quick exit from costly traditional datacentre contracts and private cloud solutions; often times these efforts take the form of a ‘lift and shift’ exercise which, whilst serving the tactical requirement of a quick exit, quite often fails to deliver on the more strategic vision of moving to the cloud in order to take advantage of its highly touted flexibility, elasticity, and cost efficiency. In other words, it’s the classic case of garbage out, garbage in.

Be that as it may many programmes of migration that I have seen are continuing to deploy into ASM and one must question that strategy now that ARM is becoming more and more mature with each passing sprint. For smaller organisations vNet to vNet connectivity between ASM and ARM has been possible for a while so the co-existence of the two has been realised since last year. For larger organisations, however, Expressroute (Microsoft.Network/expressRouteCircuits/) has been a considerable blocker. Expressroute is the facility by which an organisation can privately connect a traditional datacentre with Azure without traversing the internet. Until recently one had to create TWO Expressroute circuits if they wanted co-existence between ASM and ARM. Because Expressroute circuits have a monthly cost associated with them (varying depending on model, size, and provider) this simply equated to twice the cost for network connectivity.

Well, no more. MSFT has recently announced that it will soon be possible to have both ASM and ARM networks running over a single Expressroute circuit. So, given this new integration does it still make sense to keep deploying onto ASM or does it make sense to step back, re-assess, and invest in the necessary changes to target ongoing migration efforts to ARM? In my opinion it is the latter for three over riding reasons:

  1. Financial Accounting
  2. Security
  3. Management and Operations


Many large organisation operating under a shared services model in which a centralised body offers IT services to the rest of the organisation and its business units often wish to ‘charge back’ these services. With ASM this is near impossible at any granular level within a single subscription not to mention multiple subscriptions or tenants. With ARM, however, metadata TAGGING is the order of the day where one is able to TAG a resource to a specific owner. In fact, one can TAG at the most minute of levels; an individual NIC, for example. More common is the desire to have different workloads from different departments running under the same subscription and still retain the ability to split out the accounting for each resource and issue a separate bill of services for each department, division, or business unit. ARM enables this.


Microsoft has always embraced the concept of least-privileged access meaning that someone only has the rights necessary to perform a specific operation or function. This evolved into Role Based Access, or RBAC, which is more granular and has made its way through the Microsoft stack from Active Directory to Exchange to SharePoint to System Center, etc., and now it has come to Azure. In ASM one had a very limited set of roles to choose from:

  • Owner – full management rights
  • Contributor – full management rights except for user management
  • Reader – view resource rights

This was a major constraint from a security perspective and does not follow the ‘least privilege’ mantra.  For example, both the owner and contributor roles could delete a resource; there was no separation of duty. As an illustration of how things have now changed (this is probably not up to precise date) these are some typical roles one would find within ARM and its service providers:

  • API Management Service Contributor
  • Application Insights Component Contributor
  • BizTalk Contributor
  • ClearDB MySQL DB Contributor
  • Data Factory Contributor
  • DocumentDB Account Contributor
  • Intelligent Systems Account Contributor
  • New Relic APM Account Contributor
  • Redis Cache Contributor
  • SQL DB Contributor
  • SQL Security Manager
  • SQL Server Contributor
  • Scheduler Job Collections Contributor
  • Search Service Contributor
  • Storage Account Contributor
  • User Access Administrator
  • Virtual Machine Contributor
  • Virtual Network Contributor
  • Web Plan Contributor
  • Website Contributor

Clearly more granular. Clearly more secure.

From an authorisation perspective ARM is hands down the better platform. Indeed, from an identity perspective ARM now only supports Azure Active Directory and has deprecated X.509 certificate authentication which some will agree is more secure and others, myself included, will agree is more convenient.


Perhaps the core difference between Azure v1 and Azure v2 is that of the REST API’s underlying each. A lot of customers don’t realise that ASM is over five years old. In cloud years that’s a long time.

ARM brings with it many advantages like those already discussed but perhaps the most significant and underappreciated advantage would have to be its ‘pluggable’ model which means that future services can be seamlessly integrated. The term ‘future proof’ is almost always itself a misnomer but with ARM we get as close to it as possible.

Parallelism is a major improvement. In order to deploy 10 VMs under ASM you had to create one VM at a time. This was true whether you were scripting the process with Powershell or performing it through the portal. With ARM, however, all 10 VMs are provisioned at the same time. Equally it is much faster to decommission a complex environment: a development environment for example.

The enablement of Infrastructure as Code (IaC) is critical to achieving the elasticity and operations of any modern day cloud platform. Simplistically the cloud is asking us to reduce a datacentre into a collection of files…a lot of files. What ARM provides is a framework with which to couple, decouple, and otherwise associate these files through the JSON syntax allowing complex environments to be described and deployed in a declarative fashion. This is important because it allows for the creation of reusable templates that describe various aspects of an infrastructure that can quickly be deployed and updated and moves your organisation one step closer to the holy grail: Automation.


What I am starting to hear now on a regular basis from various forums, both public and private, colleague’s work in the field, and even some senior level MSFT architects is that now is the time to start integrating ARM into your plans. If you’re just getting started the choice is clear: ARM is the future, go with ARM.

If, however, you find yourself in the middle of a global ‘lift and shift’ and have a good way to go before your regional datacentres are fully decommissioned I believe now is the time to step back, re-assess, and invest in ARM integration. At the very least roll out the prerequisites: set up additional subscriptions if required, configure your Expressroute links, connect your vNets, and deploy supporting services like domain controllers if you’re in a hybrid situation. This will give you the option to choose whether or not to move future workloads into ASM or ARM and in future cases prevent the dreaded ‘double hop’ whereby instead of going directly to your target state you are forced to migrate everything TWICE. It’s costly, it’s complicated, and it takes up valuable resources.

One Final Thought….

The story of the ‘big bang’ approach to migrating from ASM to ARM is still being written and much of it is closely guarded. What we’ve heard, however, is that the transition largely revolves around metadata and therefore in theory could eventually be achieved without downtime. In other words, you would call up MSFT, tell them you’re ready to convert your subscription, they click a box on the back end, and voilà! Job done.

Realistically, however, when you consider the interdependencies among the components of even the most basic multi-tiered web application you quickly realise that this nirvana may be a bit further out of reach than at first glance.

**Some services have not yet been transitioned to ARM but these are few and the list keeps dwindling. Only specific cases where a required service does not exist should ASM be targeted.