https://wintermutecore.com/tags/infrastructure/Recent content in Infrastructure on Project WintermuteHugoen-usThu, 09 Apr 2026 09:00:00 +0200https://wintermutecore.com/posts/azure-sdk-v2-go-migration/Thu, 09 Apr 2026 09:00:00 +0200https://wintermutecore.com/posts/azure-sdk-v2-go-migration/<p><strong>TL;DR.</strong> Track 2 of <code>azure-sdk-for-go</code> is not a search-and-replace from track 1. Plan for a credential rework, a client factory pass, and a nil-safety sweep on every pointer chain. Lock the patterns in CI lints so the next batch ships cleaner than the previous one.</p> <p>Microsoft <code>azure-sdk-for-go</code> track 1 packages (rooted at <code>github.com/Azure/azure-sdk-for-go/services/...</code>) have been on the deprecation path for a while. Track 2 (the <code>armXxx</code> packages under <code>github.com/Azure/azure-sdk-for-go/sdk/...</code>) is the supported surface and the only one with active fixes.</p>https://wintermutecore.com/posts/aws-tag-based-resource-cleanup/Fri, 03 Apr 2026 11:00:00 +0200https://wintermutecore.com/posts/aws-tag-based-resource-cleanup/<p><strong>TL;DR.</strong> Name and time filters are not enough for safe AWS bulk cleanup. Use tags as the primary signal, expect <code>ListTagsForResource</code> to be your bottleneck, enforce tagging at provisioning time, and run an audit job that flags untagged resources so the policy stays honest.</p> <p>The &ldquo;delete a lot of AWS resources at once&rdquo; problem shows up in every account: CI sandboxes, expired test estates, dev environments forgotten about, ad-hoc reproductions left behind. Bulk cleanup tools that target this exist and work well. Used carelessly any of them is a footgun. Used carefully with tag filtering, they become one of the most useful pieces of cost discipline you can ship.</p>https://wintermutecore.com/posts/k3s-hetzner-production-notes/Thu, 05 Mar 2026 14:00:00 +0200https://wintermutecore.com/posts/k3s-hetzner-production-notes/<p><strong>TL;DR.</strong> k3s on Hetzner is a strong cost-control move when you are willing to operate the cluster. Mind the Flannel MTU on Hetzner private networks, separate stateless and stateful workloads at the storage layer, keep observability minimal but real, and treat backups as a tested practice rather than a config setting.</p> <p>A managed Kubernetes service is the right answer for most teams. When it is not the right answer (cost, control, locality of data), self-hosted k3s on a low-cost provider like Hetzner is one of the better options. We have run several clusters of this shape in production for over a year. This post is the set of decisions that have held up.</p>