Jacob Nollette, cloud & software engineer.

I build software and the systems it runs on, and I have done both ends of that for about
fifteen years. That is deliberately a generalist description, because the useful thing I do is
usually to move between layers — the bug is in the network, the slowness is in the storage, the
deploy problem is really a branching problem.

I started as a creative developer building front-ends and interactive work for web and Rails
applications, which is where I first met automated deployment. From there I spent four years at a
Minneapolis agency owning the platform behind a portfolio of client sites: consolidating fleet
maintenance across three different hosting platforms into one orchestration repository, migrating
the whole portfolio onto self-hosted source control, and building blue-green deployment on cloud
infrastructure from declarative templates.

Then four years as the DevOps engineer at a cloud-native SaaS company, where I was the sole
platform engineer for a microservice estate across four cloud projects. I rebuilt fifteen separate
deployment pipelines into a single trunk-based one and took a full rollout from most of a working
day to thirteen minutes, with security gates that block a release rather than filing a report.
Alongside that: identity federation with enforced multi-factor, disaster recovery for the
toolchain, and self-service tooling that got engineering out of the middle of routine requests.

Since then I have run my own practice, and — more to the point — a working lab that is not a
toy. Three Kubernetes clusters across three physical sites, a hyperconverged storage cluster, a
software-defined network spanning all of it, a fleet of AI agents with real jobs, and about twenty
self-hosted services replacing what would otherwise be subscriptions. It exists so that when I say
I know how something fails, I have watched it fail.

How I work

I keep an engineering changelog. Every meaningful change, decision and incident gets written
down — 248 entries since late June, 63 of them incidents — and the case studies on
this site come out of it. That habit is the single most useful one I have, and not because of the
record. It is because three unrelated-looking failures, read next to each other, are usually one
failure.

The other habit is that I do not accept a component’s opinion of its own health. A backup job
that reports success can be protecting a machine that no longer exists. A service can report
active for two months while the thing it exists to guarantee has not been true since the week it
was installed. Both of those happened to me, and both are in the write-ups. Verification asserts on
an effect in the world, or it is decoration.

I also try to be plain about the things that did not work. Several case studies here are
mostly about a wrong turn, because the wrong turn is the part that transfers.

What I am looking for

I am open to a platform, DevOps or SRE role where reliability and calm, well-communicated
engineering are valued as much as shipping fast — and I take on consulting and project work through
my own practice. Either conversation is welcome; a short note about what you are trying to build or
fix is plenty.