Automation has always been an area of debate when it comes to infrastructure. Through different conversations I had with various people, the following questions/concerns are often brought up:

I only need to deploy a couple of those servers, no need to sink time into automating the deployment

I’m a system administrator, not a programmer

Each deployment of application X is custom

I don’t have time to do automation, I need to deliver this next week

I have my trusty recipe and checklist to deploy infrastructure piece Y

Bottom line, automation is unfortunately often perceived as a significant challenge. I think the main reason it might be perceived as an difficult task is that we often look at the whole automation as a complex piece of work instead of as a composite of simple things. If you start looking at the individual actions that will bring you closer to your end result, you often realize they are not complex in themselves.

One misconception I would like to debunk is the idea that all deployments are too different to automate. That statement really reminds me of one of the principle of the Toyota Way (principle 6):

You cannot improve process before it is standardized and stable. In not stable and not standardized process there is very many variations and when trying to improve this process the result is that improvement will be just one more variation that is occasionally used and mostly ignored.

Infrastructure deployment is a process and if you cannot standardize and rationalize that process, it will be very difficult to improve the quality and speed of your deployments consistently accross the board. I think as an industry we need to sort that out. How many different automations do we need to build that achieve the exact same thing? We really need to do a better job of cultivating reusability and standardization, which ironically, for a industry that prone automation of business processes, we’re doing a pretty horrible job at this. That in itself, might be the topic for a complete blog post by itself!

OK, I was on board with the idea of standardization and continuous improvement. I did my fair share of programming in the past and have done quite a bit of PowerShell recently to solve a variety of problems. Those skills while useful are still quite a bit different than Azure Resource Manager templates or AWS CloudFormation. Why is that? Declarative infrastructure as code is a fairly different beast than the imperative/procedural alternative.

Writing PowerShell bits to deploy a VM and then handle all the possible outcomes of that operation is quite a bit different than describing how your VM should be configured and then simply shifting over the responsibility of making that happen to the cloud platform. Don’t you like the idea of just describing what you want and not having to do the job of explaining in excruciating details HOW it should be done? That’s the essence of what Azure Resource Manager templates can do for you. Couple that with the inherent benefits of scalability and programmability of the cloud platform and you truly have a powerful set of tools in your hands.

Yes, there’s a learning curve to get going. I’m not going to lie, you will need to learn new things but it’s not only worth it, I think it’s mandatory to keep progressing as an IT professional and ensure you have a future in this industry. Here’s how you might want approach this:

First there will be JSON. ARM templates are written in that notation, so you need to understand the basis format. You will need to get acquainted with the Azure resource types you need for your deployment. When you have the basics down and did a few basic resource deployments, you most likely will want to make your templates more flexible so they can serve multiple purposes. That’s probably when you will start to use things like parameters and functions in your templates. Then you’ll get into more complex deployments and will want to split things up a bit just for your own sanity, here come the linked ARM templates! If you need to get a little bit fancier with your VM deployments, most likely you will need your old friend (or enemy) PowerShell to grease the wheels a bit with some Desired State Configuration love.

Along the way, you might want to start using some sort of versioning strategy. I would highly recommend you take the time to learn the basics of Git for your ARM template source control needs.

As you can see, you can go fairly progressively into the world of declarative infrastructure as code. You start by doing a basic template for a storage account or a VM. Then you start asking yourself: “Well, if I can do this, what else can I do?” Maybe you’ll start writing an ARM template to deploy the various infrastructure tiers of an application that’s not too complex by deploying a few VMs.

Then you’ll want to do another application and realize there are bits from the other application infrastructure definition/ARM template you could reuse for this new deployment. You might be at a crossroad there. Do I refactor the previous template and perhaps make it more modular to foster reusability? That would probably a good idea! The more reusable/flexible/useful your ARM templates will be, the more chances they will get used, maintained and improved over time. That’s just the nature of the beast. Each time you improve your declarative infrastructure code, you’re sculpting the masterpiece that’s your company’s infrastructure.

I think you now get the general idea of how things will go learning/experimentation wise for ARM template deployment. So if you’re still asking, why would I want to go through this, here’s my take on answering that question. Having a good set of ARM templates will give you the following:

A repeatable way of deploying your infrastructure to Possibly recover from errors/failures by simply and quickly redeploying your infrastructure Quickly scale applications Give you consistent environment with no variations between individual deployments

Reusability Template flexibility drives reusability, reusability drives productivity up! The more you reuse code, the faster you can come up with solutions. Ultimately that means you deliver a working solution faster for your company. Reusability makes you look like a champion, because you will deploy complete infrastructure at speed and quality no human being clicking around will match

A detailed recipe of how your infrastructure is built Want to know what it takes to spin up a particular app? Go check out its ARM template, everything should be there Need to transfer ownership of deploying a particular system? Now you easily can as the recipe is self contained in the templates



In future posts, I’ll go through a few examples of ARM templates I created recently. While I’m still no master at ARM templates, I can definitely share some of my learning experiences. That might come in handy for you!

Until then, sleep on the glory of declarative infrastructure as code! OK there will be some imperative in there as well too but you get the idea! Hopefully I was able to explain why you might want to spend some time getting acquainted with Azure Resource Manager templates.