Introduction to Infrastructure as Code - Part 1: Introducing IaC

In recent years, development has shifted away from monolithic applications and towards microservices architectures and cloud-native applications. However, modernizing apps introduces complexity, as maintaining the cloud computing architecture requires infrastructure automation tools, efficient provisioning, and scaling of new resources.

Too many developers still see infrastructure provisioning and management as an opaque process that Ops teams perform using GUI tools like the Azure Portal. Infrastructure as code (IaC) challenges that notion. The practice of IaC unifies development and operations, creating a close bond between code and infrastructure.

Why should we use IaC? When you develop an application, you create code, build and version it, and deploy the artifact through the DevOps pipeline. IaC allows you to create your infrastructure in the cloud using code, enabling you to version and execute that code whenever necessary.

This three-article series starts with an introduction to IaC. Then, the following two articles in this series show how to use the Bicep language and Terraform HCL syntax to create templates and automatically provision resources on Azure.

History of IaC

We can divide the history of server management into two periods: before and after IaC.

Before IaC, IT professionals had to provision physical server infrastructure using web-based portals and command-line tools that required developers to spend time on manual tasks.

And then came the virtual machines (VM). With the advent of virtualization, “bare-metal” servers no longer limited engineers and they began to benefit from the advantages of allocating space within VMs. The use of scripts facilitated the administration of the infrastructure.

However, as they were still executing the scripts manually, engineers could still create test environments that were theoretically the same as production environments. In practice, because of human error, they contained inconsistent resources and different configurations.

Eventually, with the cloud computing era, IaC solved these issues and became an integral part of DevOps best practices. IaC technologies such as ARM templates, CloudFormation, Terraform, and Pulumi brought declarative configuration in machine-readable definition files, making infrastructure automation possible. This brought many benefits, such as predictable, consistent results in infrastructure deployments, mitigation of human-related errors, reduction of cost and risk, and version control of the definitions.

Popular IaC Tools

Let's see some frameworks and languages designed to work with IaC. While IaC templates generally do the same job, we can divide them into those designed to work with a specific cloud vendor and those designed to be platform-agnostic languages.

Some IaC templates work with vendor-specific cloud vendors such as Microsoft Azure, Amazon AWS, and Google Cloud. These prominent cloud vendors aim to create a complete ecosystem, each with their IaC solutions. These proprietary technologies typically support a more generic configuration format, such as JSON, and another format that can be a domain-specific language (DSL), designed to give more versatility and efficiency to automate resource provisioning.

Microsoft Azure

In Microsoft Azure, we can use the Azure Resource Manager templates, also known as ARM templates, which are JSON-type files with the configurations of the resources we want to create. Alternatively, we can use the Bicep language, which is built on top of JSON ARM templates to replace them, as the preferred way of doing IaC in Azure.

AWS CloudFormation

AWS CloudFormation is the standard IaC service for the AWS cloud. AWS CloudFormation templates support JSON and YAML formats and work with units called stacks. A stack is a collection of AWS resources created in AWS CloudFormation and then deployed to AWS and managed as a single unit.

Google Cloud Deployment Manager

Google Cloud Deployment Manager is the IaC service for automating the creation and management of Google Cloud resources. Google Cloud Deployment Manager templates support YAML, Jinja, and Python.

Regardless of the cloud platform, vendor-specific IaC solutions usually support a general configuration or templating languages, such as JSON and YAML, and another more robust language, such as Python, Bicep, or HashiCorp Configuration Language (HCL). This is because developers often consider JSON, with all those brackets, double quotes, and commas, to be too verbose to use as a template language and not human-readable enough for large deployments. While YAML is cleaner than JSON, it has the problem of being sensitive to white spaces, making it hard to spot and fix bugs in the code if you don’t work with a YAML-friendly editor.

Cloud vendors like Microsoft later introduced more language options to their IaC solutions. For example, we can write Azure Resource Manager templates using the Bicep language, which is easy to read and write, and comes with a code editor extension for Visual Studio Code that supports syntax checking and has an autocomplete feature. Bicep template syntax supports powerful features, including data types, parameters, variables, child resources, modules, outputs, loops, and conditions.

Bicep is a considerable improvement over JSON templates because it keeps up with every upgraded or newly added resource. Every new resource release on Azure Resource Manager is already available in Bicep syntax.

Then, there’s the case for multi-vendor tools like Terraform and Pulumi, open-source IaC tools available on GitHub. Terraform and Pulumi support multiple cloud vendors, including Azure. Multi-vendor technologies are attractive to solution developers, who don’t have to deal with different provisioning languages when working with another cloud.

From the beginning, Terraform has offered HCL, while Pulumi started with general-purpose programming languages and YAML. More recently, in addition to HCL, Terraform has added support for popular languages, such as Python, TypeScript, JavaScript, Go, C#, and Java.

The shift from JSON templates to Azure’s Bicep language was already a welcome improvement for developers. In addition, the extensive language support offered by Terraform and Pulumi to IaC allows developers to leverage their programming knowledge to create automatic infrastructure provisioning.

Software development has become increasingly complex, and it isn't difficult to find organizations working with large projects that have chosen to work with different cloud providers simultaneously. Vendor-agnostic tools like Pulumi and Terraform are well-embraced alternatives for DevOps professionals working in such diversified ecosystems.

Conclusion

Managing resources through cloud platform portals can be a tedious and error-prone activity, no matter how modern and functional the graphical interface of these web platforms is.

IaC is a process that promotes provisioning to the first level of attention enjoyed by the source code of apps and other software artifacts. IaC makes automation, continuous improvement and continuous development pipelines, fast deliveries, version control, documentation, auditing, and security much easier in a way that was not possible through cloud platform portals.

Now that we’ve discussed what IaC is, its history, and some popular IaC tools, let’s explore how to create declarations that provision resources based on the Bicep language in the second article of this series.

To learn more about how you can use Bicep to define your Azure networking resources, check out the resource Create virtual network resources by using Bicep.