What is Infrastructure as Code (IaC). Why should you care, and when should you do it.

 The term Infrastructure as Code () is everywhere, but what is it really? Something to help your company grow? Or just another fad created by people trying to sell you something?

What is Infrastructure as Code?

Your favorite vendor will tell you that IAC tools have been around since the mid 2000s and that they allow you to define and manage the configuration of your infrastructure as a series of 'code' files.

This is nonsense. Configuration Management (CM) tools have been around for a long time with products like dating back to 1993 (still developed today). Nor are configuration files the same thing as code, not even if those files are in or format. Tools like , and are themselves not IaC tools - they are strong CM tools that enable IaC for those who need it.

So then, what is IaC?

Infrastructure as Code (IaC) is when you have code that builds and manages your Configuration Management (CM) files.

Now this is hardly clear, so here are two real world examples (yeas I have personally dealt with both of these companies), one company that uses IaC, and one that only uses CM.

Company A

Company A had over 300 developers/researchers/QA working independently on a single large Software as a Service () product. Their lab environments spanned multiple clusters, and projects. Each person (or team) required one or more environments for development and testing - all told approximately 350 environments at any given time. All of these environments were built/maintained through . Changes to these environments (scale, code version, etc) were frequent, and the Terraform configuration and deployments required a three person team to keep up with all the requests.

Company B

Company B had over 200 developers/researchers/QA working independently on a single large Software as a Service () product. Their lab, PoC, and customer trial environments spanned multiple clusters, and projects. Each person (or team) required one or more environments for development and testing - all told approximately 250 environments at any given time. All of these environments were built/maintained by an piece of code built on a combination of and . When a person wanted to deploy/undeploy an environment, they wrote a minimal config file that specified environment type (out of a small list of valid options: minimal, standard, production-like, etc), location (which Openstack cluster or GCP project) and code branch(s) and fed it to the CI/CD system (). While this IaC system took a long time and several people to build, the system required zero people to actively maintain and was used for years, with only minor modifications.

A versus B

Both companies had similarly structured products, with large numbers of short lived environments. Both needed (or had decided) to run completely separate infrastructure for each such environment. But company A had decided to allow for each environment to be defined independently, while Company B decided to standardize what kinds/structures of environments would be allowed. This allowed Company B to codify those rules, and automate the entire process of environment creation, and destruction - giving the developers/QA staff the ability to spin up what they needed when they needed it.

Company A only used Configuration Management while Company B built and used an Infrastructure as Code system.

What about the modern age of Microservices?

The age of has changed many things about how many companies develop and deploy their products. What once would have required dozens (or hundreds) of separate environments can now often be achieved by having separate namespaces on a single cluster.

At datagen our IaC system allows developers to easily deploy compete environments to their own personal namespace without needing any understanding of the underlying infrastructure

Whether your infrastructure is shared by using namespaces, service meshes or something else entirely the principle is the same. IaC systems enable developers, QA, and other staff the ability to spin up standardized environments

So why use infrastructure as Code?

• You have a lot of ethereal (short lived) environments

• You can force the infrastructure design of those environments to conform to a standardized set

• The infrastructure design of those environments is expected to remain largely unchanged for several years.