Deconstructing JSON: When is VM Not Just a VM?

  • Article

One of the cool things about deploying infrastructure in Azure is all the interesting ways you can do it  – portal, PowerShell or ARM templates.  I like using the portal to help clarify what I need to set up, how I want it configured and to learn about new Azure offers quickly.  But let’s face it, we are going to have to live and die by the ARM template.

This week I decided to buckle down and really start to get my head around those JSON templates for Azure.  But looking at some of the Quickstart Templates for even the most basic VM deployments seemed like a big mess of parameters and resource dependencies. What happened to the days where a VM needed just a storage account and a cloud service?

I’ll tell you what happened: Azure Resource Manager.  ARM makes it possible to solve a lot of the design challenges that cropped up with Azure Service Manager, particularly giving cloud administrators a lot more flexibility and access to the networking functions.  This gives organizations the flexibility to design the networking in Azure to align more with what they may already have on-prem, or to optimize the cloud network for specific needs.  With greater flexibility comes greater complexity.

That “simple” VM has a few dependencies:

Virtual Machine (depends on)

  • Storage Account
  • Network Interface

Now you might look at those two things and think that it’s not much different than the dependencies from the ASM days.  You wouldn’t be far from wrong.  A storage account is still a storage account. But that network interface is a bit more work.

In the “before time” with Cloud Services, the fabric did the work of automatically creating the connection to the network, particularly if you opted to “quick create” the VM.  And even if you took the step to create a virtual network beforehand, the cloud service is what connected the VM to both the private and public networks.

Now, with ARM, you have to create and connect all the bits that used to be part of the cloud service.  If this was a physical machine, you’d be installing a NIC and running a cable to a switch port.

Virtual Machine (depends on)

  •  Storage Account
  •  Network Interface (depends on)
    •  Public IP Address
    •  VNet (depends on)
      •  Subnet

Thus, in order to deploy one Virtual Machine, you need to design and account for all the dependencies and sub-dependencies in one template.  In my next blog post, I’ll take on that very bottom item – the Virtual Network.