/ tools

ASM vs ARM & Old Portal vs New Portal

This topic comes up a lot with customers that I work with and I thought it'd be fun to write down some notes on what I see and where I see things going! First, a primer:

ASM is the Azure Service Model, which represents the original control plane for Azure, circa 2007/2008. ARM is the Azure Resource Model, which is the new control plane for all Azure services and was introduced about six months ago. ASM was designed for a different era, a different EPOCH even! It was conceived and built long before Microsoft even introduced the capability to run VMs in Azure (can you imagine those prehistoric days!?). Suffice to say, no one, including our competitors, really had any idea what kind of explosive growth and capabilities would emerge in the coming five years. There are a number of factors that lead to the decision to re-create the control plane, but at the most basic, it simply would not scale to the massive scale we see today and project for tomorrow.

Along the way, there has been some overlap in the discussions with these two control planes with the new Azure portal (portal.azure.com) which is replacing the old Azure portal (manage.windowsazure.com). I was around for the original Silverlight portal and we've come a long ways. The old portal (manage) was designed back when you could count the number of services and features in Azure on two hands. It was a great facility for onboarding new services, but as the number of features and tools grew, literally exponentially, it too wouldn't scale. Other factors like role based access control, marketplace integration, etc simply didn't exist back then so it needed a re-write for sure so it could support those new foundational elements. Because the old portal was built for the ASM control plane model, it became easy to tie the two together, but the new portal (and tooling) lives in both.

Now for a few hot button questions:

  1. When will we be retiring ASM for ARM and what do we do now to prepare?
  2. When will we get everything onto the new portal and retire the old portal?

It is interesting to observe that many people bucket these two questions together as the same conversation. I would submit that they are two very different conversations and by separating them, we can be more successful at answering both individually.

First, with regard to ASM versus ARM: Engineering efforts are currently underway which reflect the rapidly changing nature of the Azure platform. Our competition has gone through these pains as well as they've matured. When Microsoft discovered that ASM would not scale, nor would it support the needs of future services, we instrumented a change and came up with a phenomenally powerful solution in ARM. Many people complain (myself included) that ARM is so hard. Bear in mind, it’s only 6 months old and the tooling is getting better daily! ARM is MUCH more powerful than similar tools from our competitors in that it isn’t simply a template designer which just creates disparate resources. Far from it! ARM retains context, allows for updates, provides fabulous auditing and control capabilities and continues to have that context throughout the life cycle of your environment. With regard to when ASM is going to go away and ARM be required - know for certain that ASM is going nowhere any time soon and when it does, we will offer plenty of lead time, will automate as much as humanely possible and provide detailed technical guidance where that automation isn’t possible.

Second, and this hits home for me, is regarding the portal. Consider this - Microsoft introduced over 500 new production features last year alone and bringing all of the older stuff along for the ride is taking longer than we want. It impacts perception, this is certainly true. But the infrastructure, automation, programming model and interfaces via PowerShell/CLI/REST is far more important than the UI. While it is annoying, many, if not most, high usage clients rely less on the interface and far more heavily on the other tooling available - automate all the things! That being said, please do understand that the product teams are working very hard on getting the transition wrapped up as soon as possible.

By separating these two conversations, we can gain a much clearer perspective around the how and why. Know that we are moving incredibly fast but that management and control plane we spent so much time on is truly paying dividends in terms of scalability, control and safety.

Hope that helps or at least starts a great conversation!

A reminder - these thoughts are my own and not official Microsoft things.