Infrastructure as code (IaC) refers to the technology and processes used to manage and provision infrastructure with machine-readable languages (code) instead of manual operations.
IaC was first introduced around 2009 by DevOps company Puppet and is the foundation for several other companies and technologies such as Ansible, Chef, Salt, and more. In recent years, however, IaC popularity has been driven by Terraform, the open-source framework by HashiCorp. More than any other framework, Terraform has made infrastructure as code limitlessly customizable and accessible and has paved the way for the surrounding IaC ecosystem. The community surrounding Terraform is also notable for its contributions of ready-built modules.
Simultaneously, cloud providers have created their own configuration frameworks to help simplify and automate infrastructure orchestration and management. AWS CloudFormation, Azure Resource Manager, and Google’s Cloud Deployment Manager all make it easier for infrastructure engineers to build repeatable environments.
While each specific framework has its own conventions and configuration syntax, IaC is generally made up of resource declarations, input variables, output values, configuration settings, and other parameters. IaC contains all the configuration needed to spin up infrastructure, networking, load balancing, and IAM.
By using automation and predictability, IaC makes cloud provisioning and management easier overall, with several cost- and performance-related benefits.
IaC simplifies cloud provisioning by templatizing all manual configurations with automation, enabling engineers to spin up new infrastructure incredibly quickly. That speed results in incredible scalability, making it easy to apply one template to exponential VMs or resources and cost savings, allowing engineers to spend less time performing repetitive, manual provisioning work. With IaC, it’s also much easier to de-provision infrastructure when it’s not in use, decreasing overall computing costs and maintenance expenses.
Because with IaC all compute, storage, and networking services are deployed the same way every time, you can maintain consistency across resources and even across multi-cloud environments. That consistency puts human-error at a minimum and has the potential for incredibly complete versioning and logging.
IaC also encourages collaboration between developers and operators. By provisioning cloud resources across environments and clouds with a unified, common language, you can easily stay on the same page between teams.
As with any emerging technology, IaC comes with its own drawbacks, mostly related to the lack of cohesive awareness and added complexity.
Because it is relatively new, the biggest challenge IaC presents is related to understanding its intended use and embracing it fully. There is undoubtedly a learning curve to adopting IaC, which is at odds with manual infrastructure provisioning—by design. Replacing established processes and technologies can be disruptive.
Because it can also run in parallel to manual cloud orchestration, implementing IaC without full visibility and collaboration can lead to confusion as to how and where resources are provisioned. When fully embraced, its immutable nature means that instead of troubleshooting and fixing deployed resources, you simply re-provision it. When manual changes are made to IaC-provisioned resources, you lose that immutability and introduce risk of damaging services or introducing unintended behaviors.
As is the case when adding any new technology to already complex infrastructure stacks, IaC can introduce risk. Confusion and risk are only exacerbated when several frameworks are in use across teams, as is common within larger organizations.