What I do
Services
Cloud and platform engineering — the infrastructure teams deploy onto, the pipelines they ship through, and the migrations that get them there.
Twenty-five years in IT, infrastructure automation since 2017, across finance, energy, media, oil and gas, cyber-intelligence, publishing and consumer technology. The work below is what that experience is usually bought for.
Cloud and platform engineering
AWS architecture and automation with Terraform and Terragrunt. Multi-account design, identity and access as code, networking, secrets kept out of source control, and the baseline every workload inherits.
At larger organisations this is as much process as technology — deciding what a team gets by default, what they may change, and who approves the rest, then encoding that so it survives the people who agreed it.
Kubernetes
Cluster design and operation, autoscaling that responds to real demand rather than fixed replica counts, resource sizing based on measured usage, and the deployment model around it. Also the unglamorous half: why pods restart, where memory goes, and what actually happens under peak load.
CI/CD and developer tooling
Build and release pipelines, and the platforms they run on — GitHub Actions, GitLab, Jenkins, and migrations between them. Artifact repositories, code quality gates, and release automation.
I’ve moved organisations between build systems and between version control systems, which taught me that the tooling is the easy part. The work is letting hundreds of existing pipelines keep running while the ground moves, and giving people a path that doesn’t require relearning how to ship.
Migrations
On-premise to cloud. Virtual machines to containers. One build system, cloud account or region to another. A monolith’s first service pulled out of it. A database onto managed infrastructure. Legacy hosting to something that maintains itself.
The method is the same regardless: inventory what exists, find what depends on it, move in increments small enough to reverse, and verify each one before the next. Nothing moves in a big bang, and the old thing stays warm until the new one is proven.
Infrastructure as code
Everything defined in code and version-controlled — servers, DNS records, certificates, access policies, pipelines. Not for elegance, but because the result is reproducible, reviewable, and transferable to someone else.
Includes rescuing estates that were built by hand: importing existing resources into code without downtime, which is a surprisingly common starting point.
Observability and cost
Monitoring and alerting that answers real questions rather than filling a dashboard. Cloud spend reviews that identify what is actually driving a bill, right-sizing against measured usage, and commitment strategy. A first pass typically finds somewhere between a fifth and a third of the bill.
Application delivery
One platform running many workloads rather than a separate arrangement for each — APIs and services behind a gateway or load balancer, background workers, scheduled jobs, static sites on a CDN. Each one added by configuration, with routing, certificates, deployment and monitoring working the same way regardless of what it is.
The value is in the sameness. The tenth workload costs a config file instead of a project, and nobody has to remember that one of them is special.
Two shapes this commonly takes: an internal platform several teams deploy onto, and a portfolio of public-facing sites or endpoints that nobody has time to look after individually.
How engagements are usually shaped
Discovery first, priced on its own. A short, fixed piece of work to establish what actually exists before anyone commits to a number. Pricing the rest before that is guesswork on both sides, and you shouldn’t pay for guesswork.
After that, phases with something usable at the end of each — not a long build with a single delivery date. Handover, documentation and training are part of the work rather than an optional extra. Ongoing support afterwards is available but never assumed.