DEV Community

loading...
Cover image for Infrastructure As Code Is Wrong

Infrastructure As Code Is Wrong

Igor Fil
Putting 0s and 1s in correct order
Originally published at igorfil.com Ńâ╗3 min read

There are several problems in computer science that are very hard. One of them is naming things. So it should no surprise when names make little sense.

One of the "bad" names is "Infrastructure as Code". I think it misleads more than it reflects the idea.


In the era of self-hosted systems, infrastructure was managed by directly handling hardware and manually setting configurations. This approach does not work any longer in the age of cloud computing. It does not scale, it is too slow, and too risky.

Instead, the "Infrastructure as Code" (IaC) represents a different idea - to represent infrastructure and configurations as machine- and human- readable text and then use automation to manage it. These tools can create infrastructure components as many times as we like, do it very fast, and make sure they all are exactly the same.

If we take for example Terraform, provisioning of EC2 instance will look something like this:

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  tags = {
    Name = "HelloWorld"
  }
}
Enter fullscreen mode Exit fullscreen mode

It is human-readable (and writable), but it can also be processed by automation. Terraform will do all actual calls to AWS to provision the instance for us based on configurations in text files that we give it. Also, these files can be version-controlled. We can put them in git and track changes to infrastructure.

Just like code, right? But is it really code? It surely looks like it, but does not feel like it to me. What is code? Code is logic. It is either a series of imperative commands,

if this do that, else do the other thing

(C++, Java, Python, etc), or declarative computation pipelines

take data, pipe it through this function and apply this function to result

(Haskell, Elixir, Clojure, etc).
But in case of IaC, we describe the desired state of infrastructure

I want 2 EC2 instances with such and such properties

We don't specify how exactly to get them. We don't specify what APIs to call and in what order, we don't specify logic to handle dependencies between resources. Instead, we rely on Terraform (or CloudFormation) to figure that out and do it for us.

The actual logic, the code, is the tool, Terraform or CloudFormation. What we give it, that textual description of what we want, is rather data.


I have seen people take the name "Infrastructure as Code" for the face value and treat it the same way as the actual code. They try to fit loops, conditional statements and other imperative constructs into it, as if it was Java or C#. And it usually ends up pretty badly.

We should be very clear about what IaC is all about. Terraform or CloudFormation are not programming languages, not even frameworks. IaC is about being able to declaratively say what infrastructure you need and then use tools that will figure out how to get it for you. Trying to fit extensive logic into it is like trying to dig the ground with an iPhone. It can do it to some extent, but it is not what it's all about.


Infrastructure as Code seems like a very misleading term to me. When using this approach, you don't write actual code (logic) that will create infrastructure. You create configuration files that contain data that says what the infrastructure should look like. You create data, not code. That's why in my mind, "Infrastructure as Code" is actually Infrastructure as Data.

Discussion (10)

Collapse
imjoseangel profile image
Jose Angel Munoz

Thanks for the post. It makes me wonder what could the best fit between functionality, developer comfortably and classic ops comfortability.

Have you tried Pulumi? I think it can be in that mid-point.

Collapse
gklijs profile image
Gerard Klijs

If you take that a bit further SQL also isn't code. Since it's also just declaring what you want, and not how. I think your definition of code is to thin.

Collapse
igorfil profile image
Igor Fil Author • Edited

Thanks, Gerard.
It definitely makes sense. There is no hard separation, the boundaries between code and data are blurry. We can find many examples (config files, SQL, etc) that can be seen as both.
But most of all I want to give an idea that IaC ÔÇťcodeÔÇŁ should not be treated same way as Java.

Collapse
gklijs profile image
Gerard Klijs

I get that, but that's pretty trivial I think. And it's find to add functions, for example to get random passwords, in IaC. While Java with Spring Boot can be pretty declarative.

Collapse
stefiix92 profile image
Michal Štefanec

If you want to write your Infrastructure in a Java, you can use Pulumi. That's the difference between declarative and imperative IaC tools. In terraform, you write configurations, because in the end, their engine will transform all configurations to a code and makes your infrastructure look like you have in 'configuration' files. On the other hand, in imperative IaC tools like Pulumi, you need to write step-by-step code, what actually is closer to programming rather than writing desired state in the end.

Collapse
aghost7 profile image
Jonathan Boudreau

This is seems to me like the same argument against html being a programming language. Very subjective.

Collapse
igorfil profile image
Igor Fil Author

Absolutely. It all depends on angle :)

Collapse
omrisama profile image
Omri Gabay

There's a point to this. This article made me realize that infrastructure definitions that we write are very much like the idea of DDL that has been around with SQL for awhile now.

Collapse
igorfil profile image
Igor Fil Author

Thanks for your feedback, Omri!
I think that comparison to SQL is really good!

Collapse
llbbl profile image
Logan Land

There are some frameworks that sit on top of IaC that is actual "code". Also to non-tech HTML is "code" so certain some YAML is as well. Code runs everything. :D