Our cloud bill went up again last month. Not because traffic exploded — traffic was fine. The cluster just… got fatter. More nodes. Same apps. Same user count. When I dug into it, the villain was not a runaway Deployment. It was a dozen YAML files where someone typed cpu: "2" and memory: 4Gi because that felt safe six months ago and nobody ever looked again.

Kubernetes will happily reserve capacity you never use. The scheduler only cares about requests. Your finance team only cares about the invoice. Those two facts meet in the middle as slack — resources booked, paid for, and idle.

Four months into full-time work from home, my living room table is the office, the standup room, and the lab. The corporate laptop still runs Windows because that is what Visual Studio, Outlook, and the VPN client expect. The services I actually ship, though, are Linux containers. For years that meant Hyper-V VMs, slow bind mounts, and a quiet acceptance that “it works on my machine” was a slightly different machine than production.

Windows 10 version 2004 shipped WSL 2 into general availability earlier this year, and Docker Desktop’s stable channel caught up with a WSL 2 backend in May. I spent a weekend moving my local .NET Core container workflow onto it. Not because I needed another toy — because the old setup was eating evenings I no longer have spare.

Three weeks into working from home full time, I realised the thing I missed most was not the office coffee. It was the five-minute shoulder tap. “Can you look at this exception with me?” used to mean rolling a chair over. Now it means scheduling a call, fighting the VPN, and hoping the screen share does not freeze mid-stack-trace.

I am a .NET person. Most of my day lives in Visual Studio on Windows. So when the whole team got shoved onto home broadband overnight, I needed a pairing setup that did not feel like watching someone else drive through a foggy window. Visual Studio Live Share turned out to be the least bad answer we have found so far — and on a few days, genuinely better than the old way.

In graphic design, a pull quote (also known as a lift-out pull quote) is a key phrase, quotation, or excerpt that has been pulled from an article and used as a page layout graphic element, serving to entice readers into the article or to highlight a key topic.

I have been slowly getting comfortable with Kubernetes after the Docker multi-stage work earlier this year. Mostly YAML, mostly copy-paste from Stack Overflow, mostly “it works on my cluster.” Then 1.16 shipped in September and a few of those manifests started getting rejected with errors that looked like the API server had never heard of extensions/v1beta1.

That is not a bug. For the first time, Kubernetes actually stopped serving a pile of deprecated API versions. If your Deployment still says apiVersion: extensions/v1beta1, 1.16 will not politely convert it for you on the way in. It says no.

I spent part of last weekend trying to containerize a small ASP.NET Core API on my Windows laptop. The first image I produced “worked” — docker run answered on port 5000 — and then I looked at the size. Over a gigabyte for a service that is basically a couple of controllers and EF Core. That is not a deployable unit; that is me shipping the compiler to production by accident.

The fix is not exotic. Multi-stage Docker builds have been around since Docker 17.05, and the .NET team has been pushing the pattern hard as .NET Core 3.0 gets close to GA. Build with the SDK image, run with the ASP.NET runtime image, copy only the published output across. Once you see it, you cannot unsee the single-stage Dockerfile you wrote last month.