When creating single resources, e.g. a Virtual Machine or a Web App Service, it is very convenient to do it from Azure Portal. It is so convenient, that quite often we rush into creating a whole setup immediately from the portal. It is as soon as we need to copy the setup when we see that this does not scale. In this article, I will elaborate our current options for automated resource creation in Azure and their advantages and disadvantages based on my personal experiences.
When is automated resource creation necessary?
Before digging into technical details, let us first understand, when do we need to create resources automatically. This approach is my personal choice anytime I am setting up something that will stay longer than a day or two. In other words, if I am testing an idea, need a quick web app service or a storage, etc…, I go ahead and create it from the portal. If I am setting up a solution to deploy an application, then I know that eventually I will need to recreate that setup again. This could be that we will need to replicate the environment, e.g. create a staging environment. It could also be that we need to replicate the same setup in another region. In such scenarios, automating the resource creation will save you great deal of effort later.
Another reason to have resource creation automated is security. One has to be prepared for a catastrophic situation, e.g. your existing setup is not accessible anymore, then having it automated will enable you to recreate it fast and lowering your downtime.
Note: although this post is focused on options for Azure, equivalent alternative options exist for AWS Cloud as well.
Let us discuss what are our automation options?
Azure Resource Manager (ARM) Templates is the Microsoft’s recommended way of automation. These templates essentially are JSON files with a “simple” structure. They can be written using any text editor, but there is particularly good support in VS Code editor for these templates.
There are certain advantages in using ARM templates, the most important one in my opinion being the support given inside Azure. They can be very well integrated into Azure DevOps to automate infrastructure creation. I can also download the template of every manually created resource (mostly accurate), put it in source control and connect to a pipeline. Voila, from manual to automated resource creation in a few simple steps.
These templates can also be used to make sure that the infrastructure has not changed. A valid scenario is, if you run the infrastructure pipeline regularly, and if someone has changed a setting or removed a resource manually, the pipeline will correct the change and bring it to a desired state.
Also, its good integration with Azure KeyVault allows us to store secrets safely in the vault and access them easily from the pipeline, a particularly useful feature.
There are certain disadvantages about ARM templates too. They are an Azure feature and this knowledge is not reusable in other cloud platforms. Also, writing them is not super easy (though this is improving every day with better support in VS Code).
In my opinion, I would also classify the documentation about ARM templates as a disadvantage. Microsoft is improving this continuously by providing more samples and tutorials, but at the time of this writing, if you need something beyond a simple setup, finding your way will not be super easy.
Terraform is a cloud automation tool created by HashiCorp. Its support for Azure is pretty well and mature. Having multi cloud support also makes Terraform an appealing tool.
One of the main advantages of Terraform is it having multi cloud support. Even if you are not using different cloud platform, you can reuse this knowledge later when you need to use another cloud provider. The documentation is pretty decent and you can find a lot of blogs and samples on the internet. Another very big advantage is possibility to preview my changes. I can preview all the potential changes my script is going to make if I run giving me a possibility to prevent an endangering operation. This gives me confidence before executing any scripts especially against productive environments
Another favourite feature of Terraform is the workspaces. Workspaces makes it super easy to manage different environments of the same infrastructure setup.
Although terraform is advertised as a multi cloud solution, the abstraction of cloud providers are not at the desired level. Meaning, the building blocs of terraform files are cloud specific. When you create an Azure storage, it’s not the same code used to create an AWS S3 bucket.
Another big problem that can arise with Terraform is the Terraform state file. The state file contains the current state and if it gets corrupted, then one cannot execute any changes against the cloud environment. Therefore, it’s important to state it in a shared drive where all the users of the script have access to. Also, as the state file contains all the secrets applied, it itself becomes a secret you want to protect well.
Azure offers SDKs for different programming languages. They offer another programmatic alternative to automated resource creation in Azure. This could be very useful in some specific scenarios, e.g. if you want to create a custom one-stop-shop resource creation in your organisation where you can enforce your standards as well as hook resource creation to your specific organisational workflows and needs.
My experience so far in using Azure SDKs has been very limited, though I have not developed a very pleasant opinion about them. One big disadvantage that I have faced so far was that the SDK itself was not up to date with Azure. One such scenario was when creating an App Service, available options for selecting the tech stack and some other settings offered by SDK was not lacking the options available in the portal.
Overall I would say, we are lucky having many options we can choose from. I believe often which one one will choose depends on the circumstances, but I hope this list of advantages and disadvantages will help you shape your decision. In my case, I try to use Terraform whenever I can, if not then I usually fall back to ARM templates.