Did you know that there are two different Azure portals for deploying and maintaining your Azure subscriptions? For folks that have been working with Azure for some time or taking the exams, this is should be old news… for others, it might come as a surprise. So, what are the key differences and why should you be interested in the “new” portal?
Azure has had two management portals for some time now… the “new” Azure portal has been in preview for some time now and it’s about time that it has finally graduated from preview status (general availability announced on Dec 2, 2015). The new portal boasts many improvements including improved look and feel, faster startup time (50%), and faster blade load time (300%) as well as improved visibility for usage and billing details. In addition to these improvements, there are some significant differences in the underlying architecture of how resources are provisioned and managed between the two portals that many folks are not aware of.
The classic portal is based on the Service Management model (using the Service Management APIs) while the “new” Azure portal is based on the Azure Resource Manager (ARM). For compute, storage, and network resources, you can choose between classic and ARM deployment models. While resources can be deployed using either deployment model, the two models are not completely compatible with each other and in many cases, there is no path to upgrade from Service Manager to ARM for a particular resource. Microsoft recommends that all new resources should use ARM and any existing resources be considered for redeployment via ARM.
So what is Azure Resource Manager?
When you build up a system using Azure, it generally consists of many different types of resources (ie: storage accounts, virtual machines, etc.) so they are somewhat related and may be considered a group of resources. Azure Resource Manager enables you to deploy and manage resources in groups so that you can deploy, update, delete, audit, and tag all resources within a group as a single operation. You can also build up these resources as a template so they can be deployed to different environments (ie: dev, test, prod). This is especially important when you have large and complex deployments including resources in multiple subscriptions.
Generally speaking, we should be using the “new” portal whenever possible… and, while the “new” portal looks great and has many needed improvements, it is important to understand the benefits of using Azure Resource Manager via the “new” portal to take advantage of things like resource groups. Unfortunately, some functionality still lies in the old portal but Microsoft has been making great strides to bring this functionality to the new portal… in the past, it was common to have to go to both portals to build up a set of resources and services in Azure. Going forward, Microsoft is positioning the “new” portal as the single portal to spin up these services. For what it’s worth, there use to be a compatibility chart available online from Microsoft but it seems that any references to those don’t seem to work anymore… also, the pace at which these updates are getting deployed to the new portal is pretty rapid so it’s hard to keep up with the latest news. As an example, I recently attended some Azure workshops with Microsoft recently and during these sessions, the Microsoft folks themselves were checking status on certain resources to determine if they were available in the “new” portal yet or just the classic portal.
If you want to know more about the improvements and benefits of the “new” Azure portal, a good place to start is the General Availability announcment.
For more information on Azure Resource manager (ie: benefits of, deployment methods, script examples, etc.), please check out the following links: