Nitric is Terraform for Developers

As of the 29th of July this year, Terraform has been around for an entire decade! That’s right a one and a zero, Happy Birthday Terraform 🎉.

Terraform is best known for its declarative approach to infrastructure engineering, the product of which is executable documentation. Not only do we get clean documents that allow a reader to quickly reason about the architecture of a deployment, but that documentation can also be executed by Terraform to produce and execute a plan for that deployment.

Unsurprisingly, after a full decade of modern Infrastructure as Code (IaC) tooling we’re starting to see a whole new category of software emerge around it, Infrastructure from Code (IfC).

The core goal of the IfC paradigm is to bring to application development the same capability that tools like Terraform have allowed infrastructure engineers to enjoy for the past 10 years: the ability to document the requirements of our applications in a clear, concise, and executable fashion.

Using Nitric as an example:

import * as nitric from '@nitric/sdk'

// Document we need a bucket
const imagesBucket = nitric.bucket('images').allow('read', 'write')

// Document we need an API
const mainApi = nitric.api('main')
mainApi.get('/images/:key', async (ctx) => {
  // Code here
})

The Nitric SDKs allow us to not only express our requirements but also allow interaction with those requirements as well.

While these requirements can be spread out across a number of different services as files, it’s simple for us to capture this in a single highly declarative format using the Nitric CLI if we run:

nitric spec -o spec.json

Against our project, your Nitric infrastructure specification can be viewed as a simple JSON document, detailing your application’s requirements.

{
  "resources": [
    {
      "id": {
        "type": "Bucket",
        "name": "images"
      },
      "bucket": {}
    },
    {
      "id": {
        "name": "main"
      },
      "api": {
        "openapi": "{\"components\":{},\"info\":{\"title\":\"main\",\"version\":\"v1\"},\"openapi\":\"3.0.1\",\"paths\":{\"/images/{key}\":{\"get\":{\"operationId\":\"imageskeyget\",\"responses\":{\"default\":{\"description\":\"\"}},\"x-nitric-target\":{\"name\":\"api-testing_services-hello\",\"type\":\"function\"}},\"parameters\":[{\"in\":\"path\",\"name\":\"key\",\"required\":true,\"schema\":{\"type\":\"string\"}}]}}}"
      }
    },
    {
      "id": {
        "type": "Policy",
        "name": "3ed1c501e832fef808a464f42959858c"
      },
      "policy": {
        "principals": [
          {
            "id": {
              "type": "Service",
              "name": "api-testing_services-hello"
            }
          }
        ],
        "actions": ["BucketFileList", "BucketFileGet", "BucketFilePut"],
        "resources": [
          {
            "id": {
              "type": "Bucket",
              "name": "images"
            }
          }
        ]
      }
    },
    {
      "id": {
        "type": "Service",
        "name": "api-testing_services-hello"
      },
      "service": {
        "image": {
          "uri": "api-testing_services-hello"
        },
        "workers": 1,
        "type": "default"
      }
    }
  ]
}

Behind the scenes, Nitric uses this infrastructure specification to provide support for multiple clouds and IaC technologies.

If you check out this recent blog, Putting Terraform behind an API you can see how the above JSON could be provided as a payload. Suddenly you would have an API that outputs Terraform directly from application code.

The point here is that while Terraform and similiar technologies have existed for the past decade, providing Ops and Infrastructure teams with the tools they need to cleanly document their infrastructure, application development teams have had access to no such tools in this time. This is what the emergence of IfC is all about.

If you’re someone who works with infrastructure to help organisations deliver value by getting software out into the world, and care about a smooth and cohesive development experience, I would urge you to take a closer look at IfC as a whole and how you could leverage existing technology in this space or even build your own version of it.