Infrastructure you can rebuild from code

The test I apply to any environment I inherit: if this server disappeared tonight, how long until it is back, and does anyone actually know? When the answer involves someone remembering what they configured by hand in 2019, that is the problem to solve first — before performance, before cost, before anything else.

How I approach infrastructure

I came to infrastructure through running the applications on top of it, not the other way around. That matters more than it sounds: the useful decisions are made where the two meet — how the application caches, how it handles a database failover, what it does when a queue backs up. Infrastructure designed without that knowledge tends to be technically correct and operationally awkward.

Boring is a feature

Most organisations do not need a service mesh. They need environments that match, deploys that do not require a maintenance window, backups someone has actually restored from, and alerts that fire before a customer notices.

I will steer you away from architecture that is more sophisticated than your team can operate at 3am. Kubernetes is excellent and it is also a full-time responsibility; if nobody owns it, managed services and containers on simpler orchestration will serve you better.

Everything in code, including the parts that are boring

Terraform or CloudFormation for infrastructure, Ansible or container images for configuration, and the pipeline definition alongside the application it deploys. The goal is that recreating an environment is a command rather than an archaeology exercise, and that a change to production is reviewable in a pull request.

Cost is an architecture decision

Cloud bills rarely grow because of one bad decision; they grow through oversized instances nobody revisited, storage classes left at the default, dev environments running at weekends, and data transfer paths nobody drew on a diagram.

I treat cost as a design constraint rather than a quarterly cleanup — right-sizing against real usage, lifecycle policies on storage, and tagging that makes the bill legible by team or service. The savings are usually substantial and rarely require sacrificing anything.

Observability before you need it

The time to discover your logging is inadequate is not during an incident. Structured logs with request correlation, metrics on the things that actually indicate health, alerts tied to user-visible symptoms rather than raw CPU, and a runbook written by someone who has used it.

Disaster recovery that has been rehearsed

A backup you have never restored is a hypothesis. Every engagement that includes DR includes an actual restore into a scratch environment, timed, with the gaps written down. Recovery time and recovery point objectives should be numbers you have measured, not numbers you agreed to in a document.

Have a project in mind?

Describe the problem in your own words — I will tell you what I would actually build, and what I would not.

Start a conversation