Infrastructure as Code. Infrastructure is Code. Infrastructure from Code. Infrastructure will Code.
What we call IaC is not a single thing. There are a variety of different models and strategies. In this post I explore some ways to categorise these models and try to understand how IaC is evolving, including how recent advances in artificial intelligence can be a catalyst for change.
I've written about the amazing, fascinating, perhaps ultimately broken, area of Infrastructure as Code, or configuration management, before.
Curtis Collicutt
That said, I don't want to get bogged down in history here, as these conversations always end up talking about M4 and Sendmail, the demise of Chef and Puppet, and finally Terraform. Suffice it to say that things have changed, largely due to the invention of cloud infrastructure and its programmable APIs. We are now less concerned about templating a configuration file as we are with creating a relatively abstracted cloud service.
So, leaving history behind, let's talk about where things could be headed.
Putting Infrastructure Coding Methods on a Matrix
Recently I've found it useful to put things on a kind of matrix. It provides, at least in my mind, an easier way to categorise complex technology.
IaC is a good example because when we call something IaC we make it sound like it is one thing and one thing only. But it is not. There are many approaches to IaC; we're still inventing new things and evolving old ones.
At this point I have four categories that I think are important with regard to IaC. There may be more, but I believe this is a good starting point.
- As Code
- Will Code
- No Code
- From Code
Defining the IaC Matrix
X-Axis - Automation and Intelligence
Configuration is once again treated like a paint job, or a cinematic screen projection, rather than a healing operation. - https://mark-burgess-oslo-mb.medium.com/why-cant-configuration-be-made-simple-16eb70ed5455?ref=tidalseries.com
This axis ranges from "Low Automation and Intelligence" (manual processes) to "High Automation and Intelligence" (fully automated and AI-driven).
ASIDE: A word about automation. I think automation has to mean that the IaC system does something "extra" for you, i.e. if you just write a bunch of code/configuration and then run it yourself or through a CI/CD pipeline, then I believe what the code is really doing is "decompressing" the abstraction, not necessarily doing anything extra. It's not exactly what I would call automation: I want some extra intelligence in there, if I can get it.
Y-Axis - (Amount of) Bespoke Infrastructure Code
This axis measures the extent to which the IaC setup requires manual, non-application, bespoke code to define the infrastructure. It ranges from "High Bespoke Code" (requires a lot of manual coding) to "Low Bespoke Code" (minimal to no manual coding required). Using Terraform as an example, writing any relatively complex infrastructure with its domain-specific language (DSL) means writing thousands of lines of code/configuration.
As Code - High Bespoke Code, Low Automation and Intelligence
Due to the popularity of tools like Terraform, "As Code" is the easiest of the quadrants to grasp at the moment. It represents what we would consider "traditional" IaC code practices, where infrastructure is defined manually by things like scripts and/or DSL such as the Hashicorp Configuration Language (HCL).
The point is that we write code/configuration that defines the infrastructure, and then something turns that into working resources. There is typically no specialised intelligence behind the system that builds the infrastructure, instead it effectively does exactly what we tell it to do, expanding the code/config out into real running resources.
Some will take umbrage at the idea of something like Terraform being "low automation", and they may be right. However, to me, decompressing an abstraction is one thing, intelligent automation is another. It's a fine line, I admit, and one I'm still drawing.
Will Code - Low Bespoke Code, High Automation and Intelligence
This quadrant is based on the idea that we define little, if any, bespoke infrastructure code, and instead the infrastructure is built by some kind of intelligent system, likely artificial intelligence supported agents. The infrastructure "will code" itself.
This approach minimises the need for bespoke, manual coding. DevOps teams would not be putting scripts into pipelines. Platform teams would not write Terraform. Instead the "Will Code" system would inherently understand what the application needs to run and what the organisation's requirements are in terms of observability, security, resiliency, policy, etc. It would build and maintain the required infrastructure itself over time, adapting to changes with a high level of autonomy. It could be as simple as pointing "Will Code" agentic system at an applications Git repository and letting it run.
I put a large question mark in this quadrant, as it is difficult to determine–as of today–what exactly should be displayed. While I'm assuming "Will Code" will depend on AI agents they are admittedly not yet fully understood or currently practical. Thus, as far as I know, the number of working solutions in this area is near zero. There are certainly hopeful solutions, lots of ideas, lots of code, but we are just getting started in this quadrant. I'm sure behind the scenes a massive amount of funding is being put into agentic AI. Time will tell.
Current examples could be:
No Code - No or Low Bespoke Code, No or High Automation
At this time "No Code" has two sub-categories.
- So called "ClickOps": GUI driven, unrepeatable infrastructure creation and configuration
- Highly abstracted and opinionated platforms
ClickOps: The simplest way to think about "No Code" IaC is that we simply use a cloud GUI interface to click our way to the right kind of infrastructure for our applications. So there would literally be no infrastructure code written. No automation. No code. No repeatability.
Opinionated Platforms: The second sub-category is a more complicated in that it would include platforms like Cloud Foundry which require little in the way of bespoke IaC in that they inspect the app code, then build and deploy it for you. They may also build and manage supporting infrastructure such as databases. This category would typically include systems that have a high level of automation, but not much intelligence–depending on your definition of intelligence–though they are opinionated, becoming a well-trodden golden path to production.
From Code - Medium Bespoke Code, High Automation
"From Code" is the concept that we have some kind of tooling inspect our written APPLICATION code (not infra, app) and then build out infrastructure conveniences from that existing code, perhaps transpiling in some fashion to HCL or another IaC tool, and ultimately run the app as well as the underlying infrastructure. The "From Code" model would have the IaC as part of the application source code.
I expect this quadrant to be filled by programming languages which create their own tools to get applications into a working state, both locally for convenient testing and in the cloud for production. This would lead us to a situation where applications deploy themselves, using best practices that the language designers have established.
An example might be .NET Aspire combined with Radius, or perhaps Java's Spring Boot. Like "Will Code," this quadrant is being built out.
.NET Aspire components are NuGet packages designed to simplify connections to popular services and platforms, such as Redis or PostgreSQL. .NET Aspire components handle many cloud-native concerns for you through standardized configuration patterns, such as adding health checks and telemetry. - https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview
Developers define Applications and their dependencies, not the underlying infrastructure. Operators define Environments with platform configuration, infrastructure, and policies that enforce their organization’s requirements. Radius brings them together, deploying applications and infrastructure that meet both developer and operator requirements. - https://radapp.io/
More to Come
Please note that this is not meant to be an exhaustive list of all IaC-related projects, just a starting point for understanding how certain systems work and possible directions for the future.
I'll have more to say in upcoming articles, but this is what I believe a good starting point for considering "infrastructure {as, no, will, from} code".