Intermediate

For a long time my certificates renewed the way most people’s do: a calendar reminder, a manual certbot run, and a quiet hope that I’d remember before the thing actually expired. It worked. It worked right up until the morning a service threw cert errors at me and I had no idea why, because the renewal cron had been silently failing for weeks. That’s the part nobody tells you about manual TLS. The failure doesn’t announce itself. The cert just expires, usually at the worst possible moment, and you find out because a browser is yelling at someone. Renewal knowledge ends up living in one person’s head. Teams skip HTTPS on internal services because wiring it up by hand is annoying enough to put off. ...

Your metrics say something is slow. Your logs say errors happened. Great. Now answer me this: which request actually failed, where did the latency come from, and which service in the chain ate the timeout? Metrics and logs both shrug at that. I hit this wall the first time a checkout flow started timing out under load. Ten services in the path, every one of them green on its own dashboard, and no way to follow a single doomed request from front door to failure. That gap is exactly what distributed tracing fills. It follows one request as it moves through your services and shows you precisely what happened and where it stalled. ...

You’ve got Prometheus for metrics, so you can already see what’s happening across your clusters. Metrics tell you a request latency spiked at 14:32. They don’t tell you the payment service threw a null pointer because someone shipped a config change with a typo. For that you need logs. The default answer for years was Elasticsearch. It’s powerful and flexible, and it indexes every single token in every log line. That full-text index is great until you look at the bill. You pay for it in CPU at ingest, in RAM to keep the index hot, and in storage that grows faster than your actual log volume. I ran an ELK stack in a previous job and spent more time tuning JVM heap sizes than reading logs. ...

Ask most people how to run a “real” hypervisor at home and you get the same shortlist: VMware, Hyper-V, or at minimum Proxmox. Something with a web UI, a clustering tab, a marketing page full of enterprise features. That mental model is so common that running virtual machines without one of those products feels like cutting corners. We’ve quietly accepted that serious virtualization comes with a vendor attached. Now flip it. The thing doing the actual work in all of those products is a Linux kernel module that has been production-grade for over a decade. KVM with libvirt gives you live migration, memory ballooning, CPU pinning, GPU passthrough, SR-IOV, nested virtualization. The features the glossy hypervisors advertise are kernel features. The web UI is a wrapper around them. ...

I keep getting asked which distro someone should run on their daily driver: Arch or NixOS. Usually by people who already run Linux and want a workstation they actually understand, not a black box that updates itself on someone else’s schedule. I’ve run both as my real machine. Not in VMs, not as a weekend experiment. As the laptop where I do professional DevOps and platform engineering work, and as the desktop where I do everything else. So let me state my bias up front, because this framework only works if I’m honest about it: I run Arch on both my desktops today, and I run NixOS on my servers. That tells you where I landed. But I landed there for specific reasons, and I want to walk through them rather than hand you a verdict. ...