A Tale of Two Azures

Did you know that there are two versions of Azure? Yes; and they are completely different. There are also some situations and solutions that you now take for granted and will not be available to you. In this article, I’ll explain why Azure’s left brain is not talking to its right brain.

Microsoft Azure’s Split Brain

Microsoft Azure evolved into something new last year. You might not have known, but when you worked with resources in Azure, you were working with the Service Management model, also known as V1. If you worked with virtual machines in this classic deployment, then you created a virtual machine on a virtual network. A cloud service, with optional load balancing, provided a public IP address that you could implement NAT-style endpoints with.

A classic Service Management virtual machine deployment (Image Credit: Microsoft)
A classic Service Management virtual machine deployment (Image Credit: Microsoft)

Every item in that deployment was created by hand, and scaled out deployments required lots of PowerShell.
Microsoft introduced Azure Resource Manager (ARM), also known as V2, with the new Azure Portal to move to a template-based approach of deployment. This style can speed up deployment, scale it out more easily, and reduce human effort. A virtual machine deployment in ARM is very different to a Service Management one. The most noticeable differences are:

  • The cloud service is no longer used.
  • A load balancer must be constructed to create load balancing and NAT rules.

A virtual machine deployment using Azure Resource Manager (Image Credit: Microsoft)
A virtual machine deployment using Azure Resource Manager (Image Credit: Microsoft)

From an implementer’s perspective, an ARM deployment is much more complex. Currently there’s no user interface for the load balancer, and it must be built using some nasty looking PowerShell — note that I am not scared of PowerShell, but I find this feature to be off-putting.
The differences go way beyond virtual machines. Every aspect of Azure is affected. You cannot assume that if something was available in Service Management that it will be available in ARM. Some features in ARM can only be deployed via PowerShell (Azure Backup) and others do not have support yet (Azure RemoteApp).


The other big differences affect management:

  • You must be running Azure PowerShell 1.0 or later to use the generally available set of ARM cmdlets. You can access the ARM cmdlets after you log into ARM using Login-AzureRmAccount (we use Add-AzureAccount to log into Service Management).
  • The old management portal can only be used to manage Service Management. The new Azure Portal can be used to manage both a lot, but not all, of the Service Management components (no support yet for Azure Backup, Azure Site Recovery, RemoteApp or Azure AD) and ARM.

Note that if you are using the new Azure Portal, then Service Management components will appear under different blades. For example ARM virtual machines appear in a blade called Virtual Machines, and Service Management virtual machines appear in a blade called Virtual Machines (Classic).

Purchasing Azure

How you purchase Azure will affect what models of Azure are available to you. You will have both Service Management and ARM if you acquire Azure via:

  • Trial/MSDN/Direct Billing
  • Enterprise Ageement
  • Open Licensing credits

However, Microsoft has been making a big push on a new cloud sales and distribution channel called Cloud Solution Provider (CSP) since the WPC 2015 (Worldwide Partner Conference in July) of last year. This channel allows selected large resellers and distributors to resell Azure to customers and smaller resellers with monthly post-usage billing. This channel has proven to be very interesting to Microsoft partners, but there’s a catch with Azure; Azure in CSP does not support Service Management. This means that solutions that require, or might require at a later time, features are not in ARM or that are too hard to implement in ARM without a UI will not be suitable or CSP.

My Opinion

It is very early days for ARM, but I like what Microsoft wants to do. The potential to create complex solutions from templates really does simplify and accelerate deployment. It’s going to be at least five months before we have feature parity with Service Management, so those customers that are building IaaS (infrastructure) solutions probably should stick with Service Management for now. I also hope that Microsoft deals with some of the deployment complexity; the older interfaces in the Management Portal for VPN, endpoints, and availability sets are much easier to use and more reliable that their equivalent in ARM/Azure Portal. But eventually, I think Microsoft will get things right with ARM, and I’ll be happy to switch over at that time.