- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
If you’ve had any experience with Azure (and if you’re an IT pro, you should), the fact that there are two portals quickly becomes obvious. There’s the old “list-based” portal where each type of service (VM, database, storage, website, etc.) is managed in a separate part of the console. And there’s the new “Ibiza” portal (for instance, a website) where its database and any other related resources are managed as a single entity. Although plenty of links exist between these (“did you know you can do this in the new portal now?”), I mostly find myself having both open and switching between them.
Underlying the new portal is the Azure Resource Manager (ARM) framework, whereas the old one is built on Azure Service Manager (ASM).
There’s more to this than just a couple of acronyms. Microsoft is looking closely at how companies manage IT resources, the DevOps movement, and how to best enable flexibility, control, and easy deployment. All of Azure will eventually run on ARM and the preview portal will become the default.
Understanding why Azure Resource Manager exists and how best to use it will be crucial for knowing how to manage Azure deployments. It’s also going to be an important skill for on-premises deployments when Azure Stack is released next year. Smaller shops aren’t likely to bother, but this will give enterprises the exact same stack of software and interfaces that runs Azure. So the same skills and templates will be applicable to both worlds.
Resource groups
Resource groups (RGs) are collections of resources. Each resource (website, virtual NIC, database, etc.) can only be in one RG, but an RG can span multiple regions. You can therefore deploy a website to multiple Azure regions, using a single template, in one step. RGs are multiservice and will eventually span both IaaS and PaaS along with all the other services that Azure provides.
RGs also give you an easy way to monitor the application/service as a single entity. In other words, it’s about the overall health of the whole RG. In the old world, you have to know that this database is related to this website when monitoring the application with an RG that’s built in. RGs manage the lifecycle. Therefore, if you’ve created a SharePoint farm to do some testing, you can simply delete the RG when it’s done. Today, you’d have to manually delete each VM and other resources (or use a script to do so).
Resource templates
Resource templates are what you use to base one or more RG deployments on. These are JavaScript Object Notation (JSON) text files. You can use your favorite JSON editor to create and customize them; the new portal also offers a template editing experience (without syntax highlighting). Visual Studio offers additional capabilities, including drag and drop of resources (such as VMs) into a template. You can also deploy a resource template directly from within Visual Studio.
VM template in Visual Studio
Templates are also tied in with the Azure role-based access control (RBAC) framework, something that’s been sorely missing in the old portal. Because templates are parameterized, you can provide information such as the number of VMs (or databases or websites, etc.), names, locations, and SQL connection strings at deployment time. You can pass these either manually or through a parameter file. This means you could use the same template to deploy different flavors of something with different parameter files to define if it’s a dev, test, or production environment.
Resource templates are idempotent, meaning that if you already have two VMs running for a particular application but you need three more, you can rerun the deployment and Azure Resource Manager will be smart enough to know that there are three more to deploy. Templates are also declarative (similar to PowerShell DSC); you specify how you want a setup to look, not what steps should be done to achieve this state.
Relationships between resources can be defined (“depends on”) in the template so that the deployment will wait until the network interface has been created before creating the VM that should be connected to it, for instance. Parallelism is built in; if you ask for 30 VMs, they’ll all be created simultaneously, unlike scripts in the legacy ASM model. Templates can be linked to other templates, so it’s best practice to break down a larger deployment into a master template that calls other templates for parts of the provisioning.
Templates (and, by extension, deployments created by those templates) can be assigned tags, making it much easier to track applications and services. These tags (up to 15 per resource) can be for deployment stage (Dev, Test, QA, Production) and department (HR, Sales) or any other way you need to track your services in a large environment. Tags are similar to custom properties in VMM and can be used to track cost centers and the like. They also tie in with third-party solutions such as Cloud Cruiser.
No secret APIs exist behind the scenes. All three main tools to interact with Azure Resource Manager (VS, PowerShell, and the API) use the same REST calls. This means that any other deployment management tool can easily be modified to talk to ARM. Chef and Puppet are already on board, and of course the XPLAT (cross platform) Linux module for talking to Azure also manages ARM.
Exploring a template
For each parameter value, you can configure allowed values to control which regions a particular application can be deployed to (for example). You can also provide default values to guide the operator deploying it, as well as minimum and maximum limits (for example, between two and six VMs).
Numerous RBAC roles currently exist, such as Owner (which has full control, including being able to add and delete other users), Contributor (which has full access but can’t add or delete users), and Reader (which only has read access). RBAC access can also be scoped to deployments, so it’s perfectly feasible to let John in marketing log in to a slimmed-down Azure portal where he only sees the company website along with whatever available tasks that are appropriate for him.
RBAC roles can be applied to individual users, groups, and service principals. They’re inherited down from the RG to individual resources. You can also assign permissions at the individual resource level. When you add or change someone’s access level, this is audited. Note that you can’t create custom roles today, but this is coming.
Azure Resource Manager in action
To see this suite of functionality in practice, I suggest a simple test with the Microsoft-supplied website template (note that the community is also busy at work producing templates). You need a recent release of the PowerShell module for Azure. To do this, you first have to switch modes in PowerShell. Because two “ways of talking to Azure” now exist (the old ASM and the new ARM) and because cmdlets still have the same names, you have to tell PowerShell which mode you’re operating in with Switch-AzureMode AzureResourceManager. Note that, in the near future, the PowerShell cmdlet names for ASM mode will change; thus, you get a message indicating that Switch-AzureMode is deprecated.
Switching to ARM mode in PowerShell
You then need to log in (no, the old way of a publish settings file doesn’t work with ARM) with Add-AzureAccount. Get-AzureResourceGroupGalleryTemplate -Publisher Microsoft gives you a list of templates by Microsoft. Pick Microsoft.Website.0.4.0, download it, and open it in the free Visual Studio Code (or any other editor) to examine how it’s laid out.
Examining the template in Visual Studio Code
To deploy it using PowerShell, simply use New-AzureResourceGroup while pointing to the template. PowerShell will prompt you for the required names and locations. Note that, if you create resources using the new portal graphically, it’s using the same templates; therefore, for a once-off, the GUI is faster. For good measure, I redeployed the same template with the same settings. As expected, I was prompted if I wanted to update the deployment.
Deploying the website template
A more complex example would be to create a VM because IaaS VMs were recently upgraded to IaaS v2, which is another way of describing that it’s now possible to create and manage VMs using Azure Resource Manager. VMs are no longer contained within a cloud service like they were in the old ASM model. Another benefit of ARM-based VMs is that a multi-VM deployment can now have three fault domains, compared to two in the ASM model. Be aware that VMs created with ARM are not visible in the old portal; therefore, if you’re relying on shutting them down for the weekend or evening, remember to check in both portals.
Conclusion
It’s still early, but I think that ARM is going to become as important to IT pros (and developers) as AD or SQL Server. The concept of deploying multiple objects as one isn’t new in the Microsoft world. Although service templates and clouds in Virtual Machine Manager are a bleak copy of the comprehensiveness of the Azure Resource Manager framework, the same underlying concepts are present. Deploy all your applications and services “as code.” If there’s a problem, tweak the template and deploy again.
Some pieces still need to fall into place before ARM is complete. Today, you can’t easily rename a RG or move objects between RGs. An upgrade story from IaaS v1 to v2 doesn’t yet exist either. If you haven’t done so already, I suggest you sign up for the $200 trial of Azure and play with these powerful templates and concepts. It’s a lot of fun.
