Infrastracture as Code vs Infrastracture from Code

Recently I discovered the concept of Infrastracture from Code and wanted to write an article about it, since writing apart from sharing knowledge, helps me to learn myself. I am sure you are familiar with the concept of Infrastracture as Code (IaC) and you have used Terraform or Cloudformation, the goal is to express your infrastracture as code so you get all the benefits of transparency, reviewing etc that code offers. A new trend has emerge lately, the concept of Infrastracture from Code, the idea is that instead of expressing your application code seperately from your infrastracture code, the second can be inferred from the first.

Both ways aim to accomplish the same thing: simplicity and automation in the management of infrastructure. Nevertheless, they do it based on fundamentally different ways. Let’s see how:

IaC

Infrastructure as Code is a process of defining infrastructure configuration in files that are to be versioned and managed the same way application code is. Terraform, AWS CloudFormation, and Ansible are some examples of tools that do that. So, rather than simply defining configuration for the infrastructure in use, IaC places the focus on defining the desired state of that infrastructure, and the tool ensures that what’s actually deployed matches it.

provider "aws" {
  region = "us-west-2"
}

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
  acl    = "private"
}

resource "aws_dynamodb_table" "example" {
  name         = "example-table"
  hash_key     = "exampleHashKey"
  billing_mode = "PAY_PER_REQUEST"

  attribute {
    name = "exampleHashKey"
    type = "S"
  }
}

IfC

Infrastructure as Code (IfC) takes a different approach, infrastructure definitions are built into application code itself. This way, infrastructure can be created and managed along with the life cycle of an application, allowing developers to write code that automatically provisions and configures resources.

IfC empowers developers and operations teams by freeing them from the need to configure in a verbose, boilerplate manner, and from the overhead of separate provisioning. Instead, infrastructure just naturally follows the application code, introducing agility and reducing overhead. A quote mature tool in the space is Nitric.

Nitric empowers developers to define infrastructure directly in their application code with simple and intuitive APIs. Here’s how you would create a bucket with Nitric:

import { bucket, table, api } from '@nitric/sdk';

// Create an S3 bucket
const myBucket = bucket('my-bucket').for('reading', 'writing');

// Define an API that interacts with these resources
const myApi = api('my-api');

// Example API route that interacts with the bucket and table
myApi.get('/items/:id', async (ctx) => {
  const id = ctx.req.params.id;
  const file = await myBucket.read(`${id}.txt`);
  ctx.res.json({ file });
});

export const handler = myApi;

Deploying with Nitric

We can deploy our app in any of the popular Cloud Providers since Nitric supports AWS, Azure, GCP. To do that we need to create a new stack:

nitric stack new dev aws

In the nitric.dev.yaml you can define the region you want to deploy.

To actually deploy the app you can run:

nitric up

And you can tear it down:

nitric down

Infrastructure as code allows a team to work much more effectively by carrying out most infrastructure management right within the application development process. This reduces the necessity for specialized knowledge of infrastructure and allows the team to focus on delivering features and improvements, rather than dealing with infrastructure complexity.

While IfC is suitable for smaller projects or teams, it might not scale well for larger organizations with complex infrastructure needs. Advanced configurations and customizations may be more difficult to achieve compared to traditional IaC tools.

Debugging and testing infrastructure logic embedded inside application code could also be much more cumbersome. Unlike traditional IaC, in which the infrastructure could be tested independently, testing must be integrated for IfC which might make the testing procedures complex.