Imagine if all of your VM builds and configurations were predictable and consistent.

Imagine that updating the configuration of your SharePoint farm could be executed reliably from one place and applied to all 10 servers in the farm.

Imagine if the specifics of your build and configurations were executed from text rather than point and click.

This can all be realized by treating your infrastructure as code. In simple terms infrastructure as code refers to the ability to build and configure a virtual infrastructure of servers, network devices and other resources on-premises or in the cloud.

It’s a paradigm shift for engineers who are used to point and click deployments that are as variable as the individuals implementing them.

So where does one begin with infrastructure as a code? The first thing to understand about infrastructure as code is that it doesn’t just apply to the cloud. While the two are synonymous with one another and you may have only heard of the term IaC in the context of AWS or Azure, the reality is that it can be applied anywhere you deploy servers and networks.

Additionally, there is an important distinction to be made in infrastructure as code between build and configuration.

  • Build refers to the deployment of virtual servers, storage, database and or network resources in a virtual environment.
  • Configuration refers to the deployment of roles, services, software and other settings.

When it comes to the code tooling itself, what you use depends on where you will be deploying your resources. For on-premises Hyper-V or VMWare deployments, you can use PowerShell to build and PowerShell DSC to configure. In the cloud things are different because there are many different providers like Microsoft, Amazon and Google. There are also many IaC tools such as Azure Resource Manager, Terraform and AWS CloudFormation.

Some of the IaC tools like Azure Resource Manager and AWS CloudFormation are provider specific (meaning only work with Azure or AWS), whereas other tools like Terraform and Chef are provider agnostic (meaning they can work in different providers). In the case of Azure, we use Azure Resource Manager (ARM) templates to handle the build and PowerShell DSC to handle configuration.

For those interested in the code language aspect of IaC, that differs from one tool to the next with some being built on Ruby like Chef and Puppet or JSON like ARM and CloudFormation and others having domain-specific languages which are unique to the tool.

By treating infrastructure as code you can also take advantage of code management platforms like Github and Visual Studio Team Services and the capabilities they offer around work management.  Treating infrastructure in this manner becomes very powerful when you are able to trace back to the reason a certain OS was deployed or a configuration done in a certain manner because you are tracking the requirements in the same place you manage your code.

By managing infrastructure as code you foster transparency in your organization. Gone are the days of sitting through change management meetings spending for ever to explain your actions or proving that server was configured as planned. When you can see what is being deployed as part of code which has been reviewed and tested, instead of trusting that an engineer ran the correct script or followed the GUI prompts correctly you instill confidence.