As DevOps has been taking hold within the software industry there’s been a strong push towards automating everything. This include automating build, testing, deployments, as well as server and infrastructure configurations. Server and Infrastructure configuration automation was not a trivial task in the old days of on-premises datacenter where each server was on its own dedicated hardware. However, with the adoption of the cloud and Microsoft Azure along with the use of Virtualization, the automation of server and infrastructure configuration is now fairly easily done. In fact the automation of deploying servers and infrastructure is now possible through the scriptability of modern virtualization technology; such as what makes up the Microsoft Azure platform.

Automation scripts have been run for decades, this is not a new concept. However, the term Infrastructure as Code (IaC) is fairly new in the industry. As with any new term there’s starting to get a buzz around it, and with buzz comes misconceptions and misinterpretations. The purpose of this article is to describe some context surrounding the Why, What, and How surrounding Infrastructure as Code.

What is Infrastructure as Code?

Infrastructure as Code (IaC) appears to have 2 seemingly unrelated things in a single term; Infrastructure and Code. Aren’t these two very different things? Normally infrastructure refers to hardware, so how is that implemented with code?

Infrastructure as Code (IaC) is the means of writing code to perform and manage infrastructure deployments. The “Code” refers to the automation, and the “Infrastructure” is still the infrastructure you’re used to.

Infrastructure as Code doe not refer to implementing infrastructure with code. Rather it refers to the instrumentation that allows for Infrastructure to be setup and configured in an automated fashion. The Code refers to the automation, and the Infrastructure is still the infrastructure you’re used to.

Not all Infrastructure is hardware based. There are many infrastructure services within Microsoft Azure where the Infrastructure components are implemented in software. This however is something very different and not what Infrastructure as Code is about.

There are 2 different method of implementing Infrastructure as Code:

• Declarative
• Imperative

Declarative Infrastructure as Code

The declarative (or functional) approach to Infrastructure as Code is when the final state of the system is defined, or declared, in a fashion that states “What” the final state of the system is to be. When the automation process is run, it will setup or configure the system to have the declared state in the end result.

Imperative Infrastructure as Code

The imperative (or procedural) approach to Infrastructure as Code is when the automation code used to setup or configure the system is written in a fashion where it implements the configuration step by step. Automation code built this way defines the process of “How” the system is to be configured and what steps need to be taken, in exact order, to configure the system with the desired end result.

The primary key concept that both declarative and imperative Infrastructure as Code hold is that the system configuration is automated. Implementing Infrastructure as Code means to replace the manual configuration processes that have largely been used to deploy and configure systems.

Why Infrastructure as Code?

One of the big pushes of the integration of DevOps in a project, team or company is the automation of things. The things being automated are Builds, Testing, Deployments, etc. in relation to the system being built and later maintained. This automation doesn’t end with software deployments, it can easily be extended out to automating the deployment and configuration of server and infrastructure. This brings things into the realm of Infrastructure as Code.

The benefits of build automation, continuous integration, automated tests, and continuous delivery make a lot of sense in the realm of DevOps. The tasks defined by developers are automated so the system administrators that have access to the servers can execute them quickly, easily and reliably. This automation doesn’t need to end here, as it can be continued out into the tasks that the system administrators and other IT Pros perform as well.

Infrastructure as Code brings the benefits of automation, such as quicker, easier, and more reliable execute to the deployment, provisioning and configuration of Servers and other Infrastructure. High levels of automation mean that more time and money can be spent on solving business problems, rather than maintaining systems and performing tedious, repetitive tasks.

Infrastructure as Code brings the benefits of automation, such as quicker, easier, and more reliable execute to the deployment, provisioning and configuration of Servers and other Infrastructure.

Automation is a way for businesses to run more efficiently, save money, and ultimately offer levels of service to their customers only previously possible with many more resources. Automation is smart business. This is why Infrastructure as Code is an important concept and technique to adopt within any organization.

How is Infrastructure as Code implemented?

In the past technologies such as Windows Batch (.bat) files, custom command-line programs, Shell scripts or other scripting languages were largely used to perform task automation. As mentioned previously, the implementation of automating tasks is nothing new to the industry. This has been done for decades. However, there are many modern tools that take automation and Infrastructure as Code to new levels.

Two of the original methods of Infrastructure as Code automation with Microsoft Azure were to use either the Azure PowerShell SDK to script out configurations, or write a custom application using the Azure .NET SDK. These tools provide imperative approaches to implementing Infrastructure as Code on the Microsoft Azure platform.

In addition to the above mentioned Infrastructure as Code (IaC) tools, there are a number of other vendors as well. Here’s a short list of some of the other Infrastructure as Code frameworks / platforms available, including the what’s mentioned above:

• Azure Resource Manager (ARM Templates)
• Terraform
• Pulumi
• Ansible
• Puppet
• Chef
• Otter
• SaltStack
• CFEngine
• PowerShell DSC (Desired State Configuration)

There are many Infrastructure as Code platforms / frameworks available. Each one will have it’s own set of benefits and drawbacks compare to the others, as is the case when comparing any set of similar tools.

On the Windows and Microsoft Azure platforms, the answers to implementing Infrastructure as Code provided by Microsoft are largely the PowerShell DSC, and even more so with Azure the Azure Resource Manager. When implementing Infrastructure as Code in the Microsoft Azure and Azure Stack platform ecosystem the Azure Resource Manager is probably going to be the tool of choice.

While many things could be done with PowerShell or .NET to automate Microsoft Azure configuration, these tools didn’t allow for 100% of the various Microsoft Azure services to be instrumented. The result of this was the development of PowerShell Desired State Configuration (DSC) and Azure Resource Manager Templates. These two newer Microsoft Azure instrumentation methods provide a declarative approach.

NOTE: It’s worth mentioning that PowerShell DSC is a PowerShell feature and is not specific to Microsoft Azure.

Additionally, there has been some market traction within the Microsoft Azure ecosystem in the adoption of Terraform. Microsoft even recognizes this with their Azure certifications by having questions on the exams expecting knowledge of what Puppet and Chef are, and what they are used for.

Related: If you’re new to Terraform, or are looking for a bit more information, then we recommend you check out our “Get Started with Terraform on Azure” article. This will give you a great jump start to both using Terraform for infrastructure automation, as well as some tips on using it with Microsoft Azure.

What are the benefits of Infrastructure as Code?

There are several benefits of using Infrastructure as Code (IaC) over a traditional manual process for managing Infrastructure deployments. The most obvious are probably that automating processes; rather than using manual steps will run quicker and be less error prone. However, there are the following additional benefits of using IaC too:

• Automation
  IaC enables infrastructure deployments to be automated; thus reducing manual errors that can occur, in addition to increased efficiency with deployments that will generally run faster.
• Reusability
  IaC enables infrastructure automation code to be easily reused to deploy additional environments quickly; thus saving the engineering team time and resources.
• Consistency
  IaC deployments are able to provision infrastructure resources much more consistently across different environments; thus making infrastructure easier to maintain over time.
• Scalability
  IaC enables configuring infrastructure to handle scaling out to increased traffic or usage more easily; thus making it easier to handle changes in business requirements.
• Versioning
  Since IaC is written in code, and generally committed into Source Control like Git, it allows for easier change tracking, rollbacks, and team collaboration during the workflow processes of managing infrastructure environments.
• Audibility
  Automated IaC deployments make it easier to track changes and who made those changes, thus increasing the teams ability to audit infrastructure configuration and enabling them to improve security and compliance.

Wrap Up

Infrastructure as Code is a new term given to an old concept. While systems have been automated through code or scripting for decades, it’s now in a state of further innovation. The increase in automation has been inevitable since it saves money, but the more recent push of integrating DevOps has helped in its adoption.

Infrastructure as Code is all about Automating server and infrastructure setup and configuration.