In the first part of this mini-series, we introduced you to the new Azure Building Blocks (ABB) that Microsoft recently announced.

In this part, we will run through the first Azure Building Blocks (ABB) tutorial to get a feel for this new deployment process, and then afterward, complete the same deployment using an ARM template for comparison.


Installation and Setup

Although Azure Building Blocks (ABB)’s main theme is “Simplifying Resource Deployment”, there’s actually quite a few things you need to do to get started with it.

  1. First off, you need to install the Azure CLI command-line tool.
  2. Then you need to install Node.js JavaScript runtime.
  3. Finally, you have to create a directory for the Azure Building Blocks and install the Azure Building Blocks NPM package.
Azure Building Blocks - NPM Package
Azure Building Blocks – NPM Package

After doing all of that, if you want to follow along with the tutorials available, you need to clone the Azure Building Blocks (ABB) GitHub repository.

All of this to me does not feel like a “simplified” resource deployment process, especially since I can very simply open a code editor (like Visual Studio Code), and start writing my ARM template.

But, let’s continue.

After getting all of that setup, the first thing the process has you do is create an empty parameter settings file and save it as a .JSON file.

Azure Building Blocks - Blank Template
Azure Building Blocks – Blank Template


The First Tutorial

In the first tutorial, you create a single Virtual Network (VNet), with a single Subnet.

I’m not going to repeat what the tutorial already lays out, but in short, it has you copy the contents of one of the example template files (VNet-Simple.JSON), to build the parameter settings file.

In the end, your parameter settings file looks like this:

Azure Building Blocks - VNet
Azure Building Blocks – VNet


First Deployment

After you have the parameter settings file created, the only thing left is to deploy it. And for that, we have to use the Azure CLI.

This is the command-line we are told to use: azbb -g -s -l -p –deploy

Azure Building Blocks - CLI Deploy
Azure Building Blocks – CLI Deploy

The deployment actually produces an output file in the directory where your parameter settings file is located. The output looks like this:

Azure Building Blocks - CLI Deploy - Output
Azure Building Blocks – CLI Deploy – Output

Notice how it’s combined our parameter settings file and the other fields/elements passed through in the command-line.

What’s also of interest is the “deploymentContext”, which has a reference to “parentTemplateUniqueString”:”bb-01-vnet”. So, obviously, you’re reliant upon the behind-the-scenes reference template that Microsoft publishes. You don’t have control over the template itself, just the parameter settings that you feed into it. Yes, you can argue that, according to Microsoft, these reference templates are based on “proven” or “best” practices; however, that also means that you cannot tweak/customize the template if you actually had a need to (and this is the biggest reason why I’m still in favour of full/pure ARM templates).

And the results are as expected, we have our Azure Virtual Network deployed.

Azure Building Blocks - Deployment Results
Azure Building Blocks – Deployment Results



After running through this simple example, the main thing that stands out is how we don’t need to declare/code the actual resource(s). Which to some may be a welcomed change, but for others may not.

As previously mentioned, it’s a good thing because you’re relying on Microsoft’s “proven” or “best” practices for deploying resources in Azure; but, if you have the slightest need to modify the template itself (and not just the parameters), then you’re still going to need to use ARM templates.

Now let’s build the exact same VNet using an ARM template, so we can understand the differences. Let’s see ARM in action.