IaC on Azure
To start the discussion on IaC (Infrastructure as code) on Azure I have to start to have a short description on Azure. In some ways you could argue that Azure is like “your datacenter on premise but on the cloud instead” and even if that is in some ways true, it’s now really. The differences consist in for example the almost unlimited capacity without investing in new hardware, but we would say other important differences are how we can use different products without taking care on the underlying hardware and operating system. These differences demands new competences and new ways of working for an IT department.
Historically the operations team in the IT department have been in charge for setting up hardware and configuring it, installing operating systems and also in the end maybe installing the applications on the operating system itself. I believe that migrating to the cloud changes the required skills for the operations team and demands new interests. This post will though focus on one of these interests and it is the “hardware” setup and configuration in the cloud, what type of skills are needed when knowing how many “U”1 a server needs is unnecessary.
What does code what to do with hardware? Well everything, as soon as you do something in the Azure portal you are inside an application (code) that executes code which then configures the software on top of all the underlying software. Creation of a virtual machine for example in the portal asks you for information (parameters) which the application takes as inputs and then sends back to the Azure ARM (Azure Resource Management) engine. Creating a new machine asks you once again for parameters and off it goes again. This is then very similar as working with an on premise datacenter running Hyper-V or VMware virtualized environment.
So, the similarities to how operations teams have done in the past are so big that the easiest path to use the cloud is to “do the same” because at least it’s now easier because the capacity is unlimited. With unlimited capacity comes unlimited possibility to spending. What happens now is that the operations team has access to spending without approvals, this is also another topic for another day.
Anyway, as you understand this clicking to create just a virtual machine (and everything else in Azure) creates a possibility to errors in user input, forgetting important values (tags) or just takes unnecessary amount of time. I would be rich if I would have had one Swedish crown (1/8 Euro or something) every time I’ve heard in my life but it only takes a couple of minutes of my time, we don’t need to automate this, why change something that works? I would say that even if it works a hundred times in a row it never works if human interaction is part of the repetitive process. We need to develop something that is possible to repeat exactly every time. Long start of this post, now we are getting to Infrastructure as code.
Shortly described the infrastructure as code is just that instead of entering the parameters in the Azure portal you do it in code instead. The creation of a virtual machine is then “sending” your description to ARM “who” looks at what you want to create and then creates the resources for you. If you delete that resource and sends the description back in again you get the exact same resource once again, you cannot forget something if the description is in code. If you have version controlled the code and someone changes it you see what and who changed the description.
The importance here is that the creation and modification of infrastructure on Azure have to be described and version controlled in code, then it can be automated and tested. More about this in coming posts where we will describe ARM templates with and without Bicep but also Terraform and some differences. Read some MS documentation for example here2.