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"
}
}
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.
Top comments (10)
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.
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.
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.
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.
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.
This is seems to me like the same argument against html being a programming language. Very subjective.
Absolutely. It all depends on angle :)
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.
Thanks for your feedback, Omri!
I think that comparison to SQL is really good!
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