<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cloud on Chris Wagner</title><link>/categories/cloud/</link><description>Recent content in Cloud on Chris Wagner</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>cw@wagner.org.za (Chrisando Wagner)</managingEditor><webMaster>cw@wagner.org.za (Chrisando Wagner)</webMaster><copyright>© 2026 Chrisando Wagner</copyright><lastBuildDate>Mon, 03 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="/categories/cloud/index.xml" rel="self" type="application/rss+xml"/><item><title>How I Actually Make Trade-off Calls — Not Just What I Build</title><link>/posts/principal-architecture-tradeoffs/</link><pubDate>Mon, 03 Aug 2026 00:00:00 +0000</pubDate><author>cw@wagner.org.za (Chrisando Wagner)</author><guid>/posts/principal-architecture-tradeoffs/</guid><description>&lt;p&gt;If you&amp;rsquo;ve already read the build logs — the k3s cluster, the storage classes, the failover drill — you know &lt;em&gt;what&lt;/em&gt; I build. This post is about the part that doesn&amp;rsquo;t show up in a &lt;code&gt;terraform apply&lt;/code&gt; output: how I actually decide something, in the moment a plan stops matching reality, and what I do about it afterward.&lt;/p&gt;
&lt;p&gt;That&amp;rsquo;s a different question than &amp;ldquo;what technology did you pick,&amp;rdquo; and it&amp;rsquo;s the one I think actually separates senior from principal-level work. Anyone competent can execute a plan that goes to schedule. What I&amp;rsquo;m going to walk through is a plan that didn&amp;rsquo;t, twenty minutes into a homelab rebuild, and the small, unglamorous decision that followed it — because that decision is a better sample of how I&amp;rsquo;ll behave on your platform than any tool list is.&lt;/p&gt;</description></item><item><title>What I Build — A Technical Services Profile</title><link>/posts/technical-profile/</link><pubDate>Mon, 03 Aug 2026 00:00:00 +0000</pubDate><author>cw@wagner.org.za (Chrisando Wagner)</author><guid>/posts/technical-profile/</guid><description>&lt;p&gt;If you&amp;rsquo;ve landed here from LinkedIn or a referral, this is the longer answer to &amp;ldquo;what do you actually do?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;The short version: I design and build infrastructure, and increasingly I&amp;rsquo;m the one deciding what infrastructure gets built. I have done so for 25 years — across datacentres, managed service environments, banking platforms, and my own homelab — using everything from Windows Server and VMware to OpenStack, Red Hat, and modern cloud-native stacks on Kubernetes. My current role is setting cloud and containerisation strategy for a regulated banking platform: the reference architectures other engineering teams build against, the guardrails that keep a POPIA and PCI-DSS environment audit-ready, and the FinOps governance that keeps cloud spend accountable at group level.&lt;/p&gt;</description></item><item><title>I Run Kubernetes for a Bank and at Home. Here's When You Shouldn't.</title><link>/posts/kubernetes-overkill/</link><pubDate>Mon, 27 Jul 2026 00:00:00 +0000</pubDate><author>cw@wagner.org.za (Chrisando Wagner)</author><guid>/posts/kubernetes-overkill/</guid><description>&lt;p&gt;Every eighteen months or so, the same argument does a lap of the internet. Someone writes &amp;ldquo;we moved off Kubernetes and cut our infra bill by 60%.&amp;rdquo; A few months later, someone else writes &amp;ldquo;we moved back to Kubernetes and here&amp;rsquo;s why.&amp;rdquo; Both posts get the same engagement, both are right about their own environment, and both get quoted afterwards as if they&amp;rsquo;d settled something universal. Neither side did.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;m writing this because I sit on both ends of that argument at the same time, every day, and I don&amp;rsquo;t think either tribe is being honest with the other.&lt;/p&gt;</description></item></channel></rss>