One of the big advantages of using the “new” Azure Portal (https://portal.azure.com) is that it provides the ability to deploy Azure resources via the Azure Resource Manager (ARM) which I often describe to my customers as “Azure v2.0”.
Under the covers this ARM version of Azure is really just a bunch of REST web services which can be called to create, manipulate and delete resources which you normally create via the portal user interface. In fact when you use the portal you are really making real time calls to these APIs to access and retrieve the data in question.
An “ARM Template” is officially described as consisting of “JSON and expressions that you can use to construct values for your deployment” (https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authoring-templates). What this means in practice is that the content of an ARM template consists of the input data that would normally be sent as input to the ARM REST services. In other words, you don’t need to call the REST API directly, you can instead pass a template (aka a configuration file) to “something” which will do all the calling for you.
These “somethings” are correctly known as Resource Providers. Think of them as workmen that sit and wait for a template to be uploaded and if there is any work for them to do, they read their specific bit of the configuration and call the appropriate to REST API to carry out their work (whether that be creating a VM or starting a website). As Azure grows, new resource providers are added to allow the control and manipulation of that service. Rather than explain the structure of the resource template, I suggest you take some time out and read this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authoring-templates
To help people write their own templates for deploying Azure resources Microsoft (along with community contributors) have provided a whole load of examples: https://github.com/Azure/azure-quickstart-templates.
Now if you examine any ARM template, you’ll notice there are several references to an apiVersion, e.g. this JSON snippet for creating a Storage Account
What does this API Version mean?
Well if you take a look in the “Azure Schemas” repository https://github.com/Azure/azure-resource-manager-schemas, specifically at the https://github.com/Azure/azure-resource-manager-schemas/blob/master/schemas/2016-01-01/Microsoft.Storage.json file you’ll notice that it is inside folder called “2016-01-01” and you’ll find the file is called Microsoft.Storage.json. This contains the schema for the that particular version of that particular Resource Provider and in this case, that particular resource (storageAccount). This basically defines what you can pass into this Resource Provider that is understands and can create.
Ok so far? How does this relate to Azure Stream Analytics being deployed via ARM Templates? Read part 2 of this post….