<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on Panditha</title>
    <link>https://panditha.com/posts/</link>
    <description>Recent content in Posts on Panditha</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 14 Mar 2026 11:43:26 +1100</lastBuildDate>
    <atom:link href="https://panditha.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>When Flexibility Becomes a Platform Problem</title>
      <link>https://panditha.com/posts/when-flexibility-is-a-problem/</link>
      <pubDate>Sat, 14 Mar 2026 11:43:26 +1100</pubDate>
      <guid>https://panditha.com/posts/when-flexibility-is-a-problem/</guid>
      <description>&lt;p&gt;Recently I reviewed a piece of infrastructure code written by another engineer on our platform team. The implementation itself was good. It was clean, structured, and clearly thought through. The engineer had designed the system in a way that allowed a high degree of flexibility so that different configurations could be defined through variables. From a software engineering perspective, this was a solid approach. Flexible systems are often considered good design because they can adapt to many situations and avoid making assumptions too early. However, as I looked at the design more closely, something about it felt wrong. The issue was not with the code itself, but with the interface it created for the platform. That moment highlighted an important distinction that is easy to miss: the difference between building libraries and building platforms.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Knative Scale to Zero: Running Low-Traffic Services Efficiently</title>
      <link>https://panditha.com/posts/knative-serve-scale-to-zero/</link>
      <pubDate>Mon, 09 Mar 2026 09:53:20 +1100</pubDate>
      <guid>https://panditha.com/posts/knative-serve-scale-to-zero/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://knative.dev/docs/serving/&#34;&gt;Knative Serving&lt;/a&gt; provides a simple way to run HTTP workloads on Kubernetes that automatically scale based on traffic. One of the most useful capabilities is scale to zero. When a service receives no traffic, the pods disappear completely. When a request arrives, Knative starts the workload again and routes the request to it.&lt;/p&gt;&#xA;&lt;h2 id=&#34;motivation&#34;&gt;Motivation&lt;/h2&gt;&#xA;&lt;p&gt;Recently, I discussed this problem with a friend who hosts many small client services on a public cloud platform. These services are used infrequently, some only a few times per month, yet they incur continuous hosting charges. He wanted to reduce costs without sacrificing flexibility. Moving everything back to on-premises hardware seemed like an option, but it would sacrifice the ability to scale globally or easily migrate back to the cloud. Knative with scale-to-zero offers a middle ground: run a small platform at home, host services that consume resources only when actually invoked, and maintain the option to move workloads back to public cloud infrastructure if needs change. For anyone managing many lightweight internal services, especially those used infrequently, this pattern can dramatically reduce infrastructure costs while preserving operational flexibility.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Designing a 3D Printed Ant Moat</title>
      <link>https://panditha.com/posts/catty-ant-moat/</link>
      <pubDate>Fri, 13 Feb 2026 23:14:24 +1100</pubDate>
      <guid>https://panditha.com/posts/catty-ant-moat/</guid>
      <description>&lt;p&gt;We recently moved our cats’ feeding area to a room right next to an exterior door. Within a few days, their wet food started attracting ants. At first, we wanted to handle it as humanely as possible. We tried sealing entry points, cleaning thoroughly, and avoiding harsh chemicals since the bowls sit right where my cats eat. Reluctantly, I eventually tried Antrid, which worked briefly, but the ants kept coming back.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Hello Cloudflare</title>
      <link>https://panditha.com/posts/hello/</link>
      <pubDate>Wed, 11 Feb 2026 19:46:17 +1100</pubDate>
      <guid>https://panditha.com/posts/hello/</guid>
      <description>&lt;p&gt;Setting up a blog is one of those deceptively simple tasks. In theory, it’s as straightforward as: buy domain, write thoughts, publish, done. In reality, the process looked more like this: buy domain, navigate a UI labyrinth, accidentally create Workers, wonder why Hugo is deploying like a serverless function, experience an existential crisis, and repeat. Cloudflare, to its credit, is extremely powerful, but also, to my confusion, extremely enthusiastic about asking, “Are you sure you don’t want to deploy a Worker?” No, Cloudflare. I just want to publish words not edge compute, not wrangler deploys, not compatibility flags. Just text.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
