Go on Backend Engineering Strategy Tools

Pulumi

Wed, 03 Jun 2026 00:00:00 +0000

Pulumi takes the same approach as AWS CDK — use a real programming language to define infrastructure — but without the CloudFormation layer underneath. Pulumi talks directly to cloud APIs, maintains its own state, and supports multiple clouds from a single codebase.

Languages: TypeScript, Python, Go, Java, C#, and YAML. Same language across all supported clouds.

How it works

Write infrastructure as code in your language of choice. Pulumi runs the program, builds a desired-state graph, diffs against current state, and makes the API calls to converge.

import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("assets", {
 versioning: { enabled: true },
 tags: { Environment: "prod" },
});

export const bucketName = bucket.bucket;

pulumi preview # show planned changes
pulumi up # apply
pulumi destroy # tear down

State

Pulumi manages state like Terraform — a backend stores what resources exist and their current configuration. Options:

Pulumi Cloud — hosted, free tier available, adds secrets management and team features
S3 / GCS / Azure Blob — self-managed, same pattern as Terraform’s remote backend

vs Terraform

The core tradeoff: Pulumi gives you a real programming language (real loops, real functions, real tests) at the cost of a smaller ecosystem and less community tooling than Terraform. HCL is a constraint but also a simplicity — Terraform configurations are declarative and readable without needing to understand the language runtime.

Pulumi is the better choice when infrastructure logic is genuinely complex enough to benefit from a real language. For straightforward cloud resources, Terraform’s declarative HCL is often simpler to read and maintain.

vs AWS CDK

Both use real languages. The difference: CDK generates CloudFormation and inherits all of CloudFormation’s limitations (see the CDK page). Pulumi talks directly to cloud APIs, which means better drift visibility, faster deploys, and support outside AWS.

Testing

Because infrastructure is code, it tests like code:

Unit tests with Jest (TypeScript), pytest (Python), or Go test — test the resource graph without deploying
Integration tests that deploy to an isolated stack and assert against live infrastructure

OpenTofu / Terraform note

After HashiCorp changed Terraform’s licence to BSL in 2023, the community forked it as OpenTofu. If the licence change matters to your organisation, OpenTofu is a drop-in replacement. Pulumi was not affected.

Only explored in POC and lab contexts, not production. The honest take: Pulumi feels like the Gradle of IaC. The real-language argument is compelling in theory — proper loops, functions, tests, abstractions — but in practice it is easy to get wrong, and HCL’s constraint is also its strength. A Terraform configuration is readable by anyone; a Pulumi TypeScript codebase requires understanding the language runtime and the person who wrote it.

The cases where Pulumi wins: complex infrastructure logic that genuinely benefits from a real language, or teams already deep in a single language who want infrastructure to live alongside application code. For standard cloud infrastructure, Terraform is the lower-friction choice.

Dagger

Tue, 02 Jun 2026 00:00:00 +0000

Your build script works on your laptop. It breaks in CI because a tool version differs. It breaks for a colleague because they’re on a different OS. You’re writing apt-get install steps in YAML and maintaining a separate script for local builds.

Dagger solves this the same way Docker solved “works on my machine” for applications: run everything in containers. Every pipeline step executes inside a defined container image — identically on your laptop, in GitHub Actions, or inside a Kubernetes pod. The Dagger Engine is a containerised daemon your pipeline calls into. Where it runs is an operational detail; what it does is defined once in code.

The other thing Dagger gives you that YAML-based CI systems don’t: your pipeline is real code. Write it in Go (or TypeScript or Python), build a library of reusable functions, share it across projects, and test it the same way you’d test any other code.

Module

A Dagger module is a Go package that exposes pipeline functions. Initialise one in your repo:

dagger init --sdk go --name my-pipeline
dagger develop

dagger init creates the scaffolding. dagger develop generates the Go bindings and drops you into a module ready to edit. A minimal function:

package main

import (
 "context"
 "dagger/my-pipeline/internal/dagger"
)

type MyPipeline struct{}

func (m *MyPipeline) Build(ctx context.Context, src *dagger.Directory) *dagger.Container {
 return dag.Container().
 From("golang:1.22").
 WithDirectory("/src", src).
 WithWorkdir("/src").
 WithExec([]string{"go", "build", "./..."})
}

Call it from anywhere — local terminal, CI step, Argo workflow:

dagger call build --src .

Library pattern

Because a module is just Go code, you build it like any other Go library: shared types, helper functions, unit tests. The pattern that works well in practice is a single internal module that codifies your organisation’s conventions — base images, registry credentials, standard lint and test steps — and each project imports it.

A fix to the shared module propagates everywhere. You’re not updating 40 YAML files.

Testing pipeline logic with go test works normally. A test that calls dagger call exercises the real container execution, not a mock. This is the thing YAML pipelines can’t give you: a fast feedback loop on the pipeline logic itself before it hits CI.

Multi-arch builds

Dagger has first-class support for multi-architecture container builds. Pass the platform as an argument:

func (m *MyPipeline) BuildMultiArch(ctx context.Context, src *dagger.Directory) []*dagger.Container {
 platforms := []dagger.Platform{"linux/amd64", "linux/arm64"}
 containers := make([]*dagger.Container, len(platforms))
 for i, platform := range platforms {
 containers[i] = dag.Container(dagger.ContainerOpts{Platform: platform}).
 From("golang:1.22").
 WithDirectory("/src", src).
 WithWorkdir("/src").
 WithExec([]string{"go", "build", "./..."})
 }
 return containers
}

Same function, multiple targets, no extra tooling.

Running in Kubernetes with Argo Workflows

Dagger Engine runs as a container. In Kubernetes, you run it as a sidecar or dedicated pod and point dagger call at it via the _EXPERIMENTAL_DAGGER_RUNNER_HOST environment variable. Each Argo Workflows step calls dagger call <function> — Argo handles DAG orchestration, retries, and observability; Dagger handles the build execution inside containers.

The split is clean: Argo owns workflow-level concerns, Dagger owns build reproducibility.

Key commands

Command	What it does
`dagger init --sdk go`	Initialise a new module with the Go SDK
`dagger develop`	Generate bindings, enter the development loop
`dagger functions`	List available functions in the current module
`dagger call <function> [args]`	Invoke a pipeline function
`dagger run <command>`	Run an arbitrary command with Dagger Engine available

Dagger Cloud

Dagger Cloud is a hosted observability layer for Dagger pipelines. Free tier available.

Every pipeline run — local or CI — produces a trace: a visualisation of the container graph with per-step timing, cache hit/miss, and log output. The trace is linked from the terminal output and browsable at cloud.dagger.io.

Enable it by setting one environment variable:

export DAGGER_CLOUD_TOKEN=<token>
dagger call build --src .
# → Run URL: https://app.dagger.cloud/runs/<id>

In GitHub Actions, add DAGGER_CLOUD_TOKEN as an organisation-level secret (see GitHub Actions). The dagger/dagger-action picks it up automatically — no workflow change needed beyond the env var being present.

Resources

Go

Mon, 01 Jan 2024 00:00:00 +0000

Go is my go-to language for backend services, CLI tools, and DevOps tooling. The standard library covers most of what you need, the compiler is fast, and the concurrency model (goroutines + channels) makes it well suited for infrastructure-adjacent work.

Tooling

IDE: GoLand: JetBrains’ Go-specific IDE. Solid refactoring, built-in debugger, good test runner integration.

Formatting: gofmt / goimports: no debates about style, just run it.

Linting: golangci-lint: meta-linter that runs a configurable set of linters in one pass. Worth wiring into CI.

Testing

Testing is built into the standard library — go test ./... is all you need to get started. Table-driven tests are the idiomatic pattern for covering multiple cases cleanly.

func TestAdd(t *testing.T) {
 cases := []struct{ a, b, want int }{
 {1, 2, 3},
 {0, 0, 0},
 }
 for _, c := range cases {
 if got := Add(c.a, c.b); got != c.want {
 t.Errorf("Add(%d, %d) = %d, want %d", c.a, c.b, got, c.want)
 }
 }
}

Resources

Hugo

Mon, 01 Jan 2024 00:00:00 +0000

Hugo is a static site generator written in Go. Content is Markdown, templates are Go HTML templates, and the output is plain HTML/CSS/JS — no server-side runtime, no database. Build times are fast even for large sites; most builds complete in under a second. This site is built with Hugo.

Structure

content/ # Markdown pages — mirrors the URL structure
layouts/ # Template overrides (Hugo prefers local files over theme files)
assets/ # CSS, JS, images processed by Hugo Pipes
static/ # Files copied as-is into the output
themes/ # Theme(s), typically pulled via Go modules
config.yaml # Site configuration

Content files use YAML front matter to set metadata:

---
title: "My Page"
date: 2026-06-04
draft: false
tags: ["example"]
---

Page content here.

Themes via Go modules

Themes are imported as Go modules in go.mod. To override a theme template or style, mirror the file path under layouts/ or assets/ — Hugo’s lookup order prefers local files over theme files, so the override takes effect without touching the theme itself.

Build and serve

# Serve locally with draft and future content enabled
hugo server -D --buildFuture

# Build to public/
hugo --minify

Sections and taxonomies

Hugo’s content model is built around sections (top-level directories in content/) and taxonomies (tags, categories). Each section and taxonomy gets its own listing page automatically. _index.md in a section directory controls the listing page’s content and front matter.