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.
- First off, you need to install the Azure CLI command-line tool.
- Finally, you have to create a directory for the Azure Building Blocks and install the 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.
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:
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
The deployment actually produces an output file in the directory where your parameter settings file is located. The output looks like this:
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.
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.