100-year old Makefiles with public cloud deployment templates

Sometimes we find ourselves with modern day problems, that have 100-year old solutions that still work great πŸ™‚Β I find this is the case with Makefiles, and make easy to use repeatable deployment templates with the public cloud providers. I want to explain in this article how simple Makefiles can make working with cloud deployment templates more easy for both experienced and new users.

Problem Introduction

Each of these providers has their own deployment template language – with AWS it’s CloudFormations templates, with Azure it’s ARM templates, with GCP, there are Deployment Manager templates. Each of these effectively do the same thing, that is to define a deployment as code (ie, infrastructure as code).

Defining deployments and infrastructure as code has many advantages, most notably, making it easy to repeat and iterate on with improvements. However, it can be really tedious to keep running commends like [cci lang=”bash”]cloud-deployment-tool -f mytemplate.json -g myGroup -e production …[/cci], not to mention it’s quite error prone and difficult for other users in your team to get started with. Introducing our 100-year old solution that still works great.

Introduction to Makefiles

Makefiles were created a long time ago, okay, maybe not quite 100 years ago, but if you’ve used any Linux/Unix like operating system you’ve probably bumped into them. They’re intended to be used much like scripts, but were specifically designed for building source code. When working with source code, there are many common operations like cleaning out old artifacts, building a new version and updating some metadata files. Programmers use Makefiles to automate these common operations, let me show you a quick example;

    rm -rf bin/

    gcc myprogram.c

    echo date > VERSION.txt

.PHONY: clean build update

Implementing this for the Cloud Provider’s templates

So, how can we use these Makefiles for each of the cloud providers? Lets Look at each example indvivdiaully.

Azure (ARM Template)

 user@host: tree
 β”œβ”€β”€ Makefile
 β”œβ”€β”€ myDeployment.parameters.json
 └── myDeployment.json

So, lets take a look at what this Makefile might look like to go with the arm template (myDeployment.json) and the parameters file (myDeployment.parameters.json). We define 3 simple goals; validate, deploy, clean and a helper goal, retry.

    az group deployment validate --resource-group myGroup --template-file myDeployment.json --parameters @myDeployment.parameters.json

    az group deployment create --resource-group myGroup --template-file myDeployment.json --parameters @myDeployment.parameters.json

    az group delete -n myGroup
    az group create -n myGroup --location "West Europe"

That’s it! very simple. Of course you’d need to have the az command installed and authenticated, but Makefiles provide for really nice shortcuts as you can see.

AWS (CloudFormations)

Under development 😐

 user@host: tree
 β”œβ”€β”€ Makefile
 └── awsTemplate.json

GCP (Deployment Manager)

Under development 😐

 user@host: tree
 β”œβ”€β”€ Makefile
 └── gcpTemplate.json

Why don’t I just use a bash script?

You absolutely could just use a bash script, the principle is almost the same. However, as the number of goals/shortcuts you has increases, bash scripts tend to get messy fast. Why bother writing code to check which goal needs to run when Makefiles do this by default as well? Just unneeded complexity in most cases. Of course you could separate your goals into separate bash scripts, like ./deploy.sh, ./clean.sh, and similar, but you’re going to get a couple of scripts over time. Makefiles keep everything in one place that is very easy to use.

Summary: What does this get me?

Using simple makefiles with these complex deployment templates makes your deployments a little more human-friendly. Others in your team can share these templates and not worry so much about “which parameters do I need?”, or simply “how do I run this?”. When you get a little more used to using these templates as well, you can feel more confident that you can re-run these easily, efficiently, and without changing the parameters each time – this makes your deployments far more repeatable.

If you get further down the road of integrating CI (like Jenkins) into your deployments, these Makefiles can make your build jobs a lot more easy and repeatable there as well. Give it a try – an old tool used for a new purpose!

Exam 70-533: Implementing Microsoft Azure Infrastructure Solutions

DISCLAIMER:Β The information contained in this blog post is as accurate as possible as of Summer 2017; it is essential that you also validate this with the official reference pages as they will be updated with current exam objectives and guidance, this blog post might not be!

What is this exam about?


Did I find this exam useful?


How did I prepare for 70-533?

I’ve identified that over the years, my preferred learning style is very much being self-taught, rather than sitting in a classroom and being lectured. This is mostly a personality thing, I get grumpy listening to other people talk for hours, and I very much like to explore topics and subjects beyond the course material that is often presented to me. While some courses I’ve been on have been excellent, I decided that I’d also attempt this exam after being self-taught.

Structure your learning with the exam objectives and traffic lights

Teaching yourself any subject, especially one as massive as Azure has to be done in a structured way. I started off with the exam objectives and rated myself where I thought I was. This can be very useful to give yourself a quick “heatmap” of how much learning you think you have to do, even if you just use a simple traffic light coloring scheme;

  • Deploy Web Apps
    • Define deployment slots; roll back deployments; implement pre- and post-deployment actions; create, configure and deploy packages; create App Service plans; migrate Web Apps between App Service plans; create a Web App within an App Service plan
  • Configure Web Apps
    • Define and use app settings, connection strings, handlers and virtual directories; configure certificates and custom domains; configure SSL bindings and runtime configurations; manage Web Apps by using Azure PowerShell and Xplat-CLI
  • Configure diagnostics, monitoring and analytics
    • Retrieve diagnostics data; view streaming logs; configure endpoint monitoring, configure alerts; configure diagnostics; use remote debugging; monitor Web App resources

…. and many more objectives!

With this heatmap, I always tend to start with the red items first. Why start with the stuff I don’t know well? Simply, as you start to look through these, you often pick up bits and pieces from other topics that you might partially know, and I found this with Azure in particular. In configuring diagnostics and monitoring, it really helped me out diagnosing VM and web app deployment for example.

Practice tests!

How long did you have to learn for?

This really is different for every person. I’d personally been using Azure (fairly casually) before the exam for several months, and I put in several 4-6 hour evenings prior to my first take of the exam.

It took me a while with this one; I passed on my third attempt which is pretty frustrating! I’ve failed some technical exams in the past, but generally I pass them first time because, if you review the objectives, if you put in the learning hours, passing first time is just a matter of good preparation. However, with this exam I under-estimated on my first 2 attempts just quite how much emphasis it puts on memorizing complex tables and support structures, as well as relatively nit-picky questions about PowerShell syntax (pretty much not used now that the azure cross platformΒ command line interfaces are available). Unfortunately, those are my two issues with this exam.

Essential Reading

  • https://www.microsoft.com/en-gb/learning/exam-70-533.aspx

Recommended Reading

  • Certifications? Pah, I have experience!