Last year I wrote about distroless containers and finished with a small brag: I build my own minimal base image with apko and Wolfi, look how tiny it is, look how few packages it has.

This year I held that image against the standards that serious hardened-image vendors compete on. It failed.

Not because of what was inside the image. The contents were fine. Six packages, no shell, non-root user, signed with Cosign. It failed because of everything around the image and that is exactly where the state of the art has moved.

Early in my career, I assumed everyone worked the same way I did. I thought “professional” meant universal and that technical rigor transcended culture. I was not just incorrect, I was naively wrong.

I’ve spent about twenty-five years working in infrastructure engineering, almost always in multinational distributed teams. I’ve been the formal manager of an infrastructure team twice in my career, but mostly I’ve been on the other side, a team member trying to figure out how to work with people who think, communicate, and collaborate completely differently than I do. Right now, I’m in a team of seven people where every single person has a different nationality, trying to help, enable and influence while “my way” might not be “their way.” I misjudge people’s preferences regularly and have to repair trust after the fact. It’s uncomfortable every time, but it’s part of the process.

I didn’t sign up to be a project manager. I got into programming because I loved the exploration, making mistakes, finding solutions and moving slowly bit by bit. One day I needed system tool then I wrote some C, the other time I needed some glue code, so I got comfortable with Perl or Bash. Needed to created website? Well… PHP was the languge for it - basically whatever was up to the job. I never learned any of these to the level of a professional, was never interested.

I’ve enjoyed solving puzzles, one at the time, it was creative freeform craft. It was messy, it was dounting. It was fun, sooo much fun!

Now I spend my days writing prose about code instead.

Kent Beck calls AI code agents the genie in the bottle: you get what you wish for, not what you want. He’s right, but in ways I did not expected.

One of the things I care deeply about is helping other engineers grow. Over the last year, I’ve had a lot of conversations, some with folks just entering the field, others with seasoned pros, asking the same question: how is AI going to reshape our work? There is fear and uncertainty, but also some optimism.

There’s a rhythm to these tech cycles.

I’ve seen it before, big promises, huge hype, sweeping predictions. Right now, we’re being told that AI will replace entire roles, maybe entire industries. It’s the same energy we saw with self-driving cars. For years, we were told they were just around the corner. But today, in 2025, I still don’t see a 40-ton truck rolling down the Autobahn without a driver. Waymo works, yes, but in tightly controlled areas, in a few cities. Meanwhile, here in Europe, truck drivers are still very much in demand.

Ever found yourself knee-deep in a routing incident at 3 AM, frantically switching between terminals and browser tabs trying to piece together BGP data? I’ve been there. You’re chasing down a routing anomaly, your coffee’s gone cold, and you’re clicking through endless forms just to figure out which AS is announcing that suspicious prefix.

What if I told you that instead of switching between terminals and browser tabs, you could use natural language to describe the problem, and then ask the computer to do the work for you?

If you’ve been in the container game for a while, you’ve probably seen a lot of buzz around “distroless” containers. The first time I heard the term, I pictured a container floating off into the void - no OS, no shell, just… code. Turns out, that’s not too far from the truth, but just like Serverless, Distroless is a misleading term!

Let’s break down what distroless containers are, why you might want them in your stack, what they’re great at (and not-so-great at), plus how to actually debug one.

I’m happy to announce a simple yet effective command-line DNS benchmarking tool I’ve recently developed: dns-benchmark. This project was directly inspired by the outstanding work of Steve Gibson and his well-known DNS Benchmark utility. Steve’s meticulous attention to detail in benchmarking DNS performance motivated me to create something similar, but tailored specifically for the command line.

This CLI tool, written in Go, allows individual users to quickly test and compare various recursive DNS servers, checking key metrics such as latency, reliability, DNSSEC validation, and even response correctness—like detecting servers that hijack NXDOMAIN responses.

As infrastructure engineers, we often find ourselves bridging gaps between the tools we use and the monitoring systems we rely on. When I’ve migrated to Prometheus and Grafana on one of the sites, integrating Accel-PPP posed a unique challenge. The absence of native Prometheus support for Accel-PPP meant I was stuck with an SNMP-based monitoring setup, but relying on SNMP for metrics felt like patching a modern system with legacy tools—inefficient and less than ideal. Additionally Accel-PPP lacks any API or interface to get information about its state. This led me to develop accel-exporter.

Over my two decades as an infrastructure engineer, I’ve watched our field transform dramatically. What began with manual server configuration has evolved into defining entire organizations infrastructure as code. This journey reflects not just technological change, but a complete shift in how we approach managing systems at scale. I’ve been in the trenches through most of it, and I want to share my story of this evolution with fellow infrastructure engineers who’ve lived through similar transitions.