0 Comments

Azure ARM templates allow you to automate your environment setups. But with a cost. Dealing with the long JSON-files is hard, even though there are visualizers like ARMVIZ available.

What can we do? In this series I’ll explore the options for automating your Azure environment setup.

Background

If you can create a completely new and fresh Azure environment for your system with a click of button, with everything deployed automatically, you’re in the happy land. If you can’t and setting up the environment requires some manual work, you should aim to automate the process completely. If you run the automated process twice, we want to end up with two identical systems but with the following differences: Each installation should have their own passwords and own urls.

ARM in Azure’s context stands for Azure Resource Manager. The key scenarios for ARM, as defined in the documentation, are:

  • Deploy resources together and easily repeat deployment tasks
  • Categorise resources to clarify billing and management
  • Enable enterprise-grade access control

We’re mainly interested in the first key scenario: How to automate your deployment.

When we use ARM, we’re using JSON based ARM-templates. We deploy the JSON-file, which Azure Resource Manager then converts to REST calls and the REST calls create the required resources. The key thing is that we only have to care about our JSON-template, ARM takes care of the rest.

Problem

ARM templates are great because they allow you to automate the environment setup. But they come with a cost: ARM templates tend to grow to these huge, almost monstorous JSON-files which are hard to understand and to maintain. And as we know, maintanability is the key when we want our systems to have a long life.

GitHub has a great source for templates. You can create simple and complex environments with these templates, ranging from something simple as Windows VM to MongoDB high availability installation. But if you look at these templates you can easily see the problem: the simple Windows VM is 179 lines of JSON. MongoDB is 500 lines.

Personally I think that the problem with ARM templates is obvious: The templates try to use JSON in a situation where it isn’t build for. In theory you can use JSON to describe your environment. But to actually make things work you need some concepts from programming languages:

  • Variables
  • Conditions
  • Loops

XML and JSON are both great ways to describe static data but they fall short when you try to “programming languagefy” them. ARM templates aren’t the only one with the same problem: If you check the JSON-file behind the Azure Logic App, you usually find a mess. If you try to use text editor for editing a Mule ESB flow, you will encounter problems.

Options

Given that the aim of an automated environment setup is great but ARM templates are hard to maintain, what can we do? I personally believe that instead of trying to make JSON to act like a programming language, we should use an actual programming language.

So instead of using an ARM template to describe your environment, you create a C# console application to describe and to create your environment using Azure Management Libraries for .NET.

Or if your environment is simple, you can use .bat-files (Azure CLI) or Powershell scripts (Azure Powershell) to automate your environment setup.

Conclusion

This post was aimed to give you the background. In the following posts I will explore and compare three options for automating your Azure environment setup:

  • ARM templates
  • Azure Management Libraries for .NET
  • Azure CLI