From f001c85574dae7ab2fe340de4a61c193c4fd9fb6 Mon Sep 17 00:00:00 2001
From: Mac Chaffee <me@macchaffee.com>
Date: Sat, 23 Nov 2024 23:32:59 -0500
Subject: [PATCH] Add you-have-built post

---
 blog/2024/index.html                          |   6 +
 .../you-have-built-a-kubernetes/index.html    | 135 ++++++++++++++++++
 blog/atom.xml                                 |  31 +++-
 blog/index.html                               |   6 +
 blog/sitemap.xml                              |   4 +
 .../2024-11-23-you-have-built-a-kubernetes.md |  23 +++
 6 files changed, 204 insertions(+), 1 deletion(-)
 create mode 100644 blog/2024/you-have-built-a-kubernetes/index.html
 create mode 100644 blog_zola/content/2024/2024-11-23-you-have-built-a-kubernetes.md
diff --git a/blog/2024/index.html b/blog/2024/index.html
index 222f4ee..b4ea0c8 100644
--- a/blog/2024/index.html
+++ b/blog/2024/index.html
@@ -94,6 +94,12 @@ <h1>2024</h1>
         <div class="border"></div>
         <ul>
         
+            <li>
+                <a href="https://www.macchaffee.com/blog/2024/you-have-built-a-kubernetes/">
+                    Dear friend, you have built a Kubernetes
+                </a>
+            </li>
+        
             <li>
                 <a href="https://www.macchaffee.com/blog/2024/tunneling/">
                     Flouting the Internet Protocols with Tunnels
diff --git a/blog/2024/you-have-built-a-kubernetes/index.html b/blog/2024/you-have-built-a-kubernetes/index.html
new file mode 100644
index 0000000..f8641e4
--- /dev/null
+++ b/blog/2024/you-have-built-a-kubernetes/index.html
@@ -0,0 +1,135 @@
+<!DOCTYPE html>
+<html lang="en">
+    <head>
+        
+        <meta charset="utf-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1" />
+
+        <meta name="description" content="Mac&#x27;s Tech Blog">
+        
+
+        <title>Dear friend, you have built a Kubernetes</title>
+
+        
+
+
+<link rel="alternate" type="application/atom+xml" title="RSS" href="https://www.macchaffee.com/blog/atom.xml">
+
+<meta name="image" content="https://www.macchaffee.com/static/favicon.png">
+<meta property="og:image" content="https://www.macchaffee.com/static/favicon.png">
+<meta name="theme-color" content="#1b2b34">
+<link rel="shortcut icon" href="/static/favicon.png" type="image/png">
+
+<meta property="og:title" content="Dear friend, you have built a Kubernetes">
+
+<meta property="og:description" content="Mac&#x27;s Tech Blog">
+
+<link rel="stylesheet" href="https://www.macchaffee.com/blog/theme.css">
+<style>
+body {
+    font: 400 18px/1.6 "Helvetica Neue", Helvetica, Arial, sans-serif;
+    color: #dbe0ea;
+}
+h1 {
+    font-size: 47px;
+}
+ul {
+    list-style: disc outside;
+    padding-left: 1.5em;
+}
+code {
+    font-family: monospace;
+    font-size: 16px;
+}
+.search-box {
+    background-color: #101a20;
+    border: 2px solid #36596c;
+    font-size: 20px;
+    line-height: 2;
+    color: #c0c5ce;
+    margin-top: 10px;
+}
+/* Overrides */
+p {
+  text-align: left;
+}
+p > code {
+  font-weight: normal;
+  padding: 1px 5px;
+  color: #a7adba;
+  background-color: #101a20;
+}
+h2 {
+    font-size: 24px;
+    border-bottom:1px solid #99c794;
+}
+blockquote {
+    color: #a7adba;
+    font-style: italic;
+}
+</style>
+
+        
+    </head>
+    <body>
+        <div class="content">
+        
+        
+            <header>
+                <div class="header-left">
+                    <a href="https:&#x2F;&#x2F;www.macchaffee.com&#x2F;blog" class="logo">Mac&#x27;s Tech Blog</a>
+                </div>
+                <div class="header-right">
+                    <nav itemscope itemtype="http://schema.org/SiteNavigationElement">
+                        <a itemprop="url" href="https:&#x2F;&#x2F;www.macchaffee.com&#x2F;blog/atom.xml">
+                            <img class="icon" src="https:&#x2F;&#x2F;www.macchaffee.com&#x2F;blog/icons/rss.svg" alt="RSS Feed">
+                        </a>
+                    </nav>
+                </div>
+            </header>
+        
+        
+        <main>
+            
+<article itemscope itemtype="http://schema.org/BlogPosting">
+    <div itemprop="headline">
+        <h1>Dear friend, you have built a Kubernetes</h1>
+        <div class="border"></div>
+        <time datetime="2024-11-23" class="date" itemprop="datePublished">
+            2024-11-23
+        </time>
+    </div>
+    <div itemprop="articleBody">
+        <p><em>This post will make more sense if you first read <a href="https://rachit.pl/post/you-have-built-a-compiler/">Dear Sir, You Have Built a Compiler</a>.</em></p>
+<p>Dear friend,</p>
+<p>I am afraid to inform you that you have built a Kubernetes. I know you wanted to "choose boring tech" to just run some containers. You said that "Kubernetes is overkill" and "it's just way too complex for a simple task" and yet, six months later, you have pile of shell scripts that do not work—breaking every time there's a slight shift in the winds of production.</p>
+<p>Surely, switching to Docker Compose will be the end of your woes; at least that way, someone else maintains a standard config file format for you to use. But wait, Compose is still <a href="https://www.macchaffee.com/blog/2024/docker-compose/">not a holistic solution</a>. "Do I really need a separate solution for deployment, rolling updates, rollbacks, and scaling?" you ask yourself? Surely not. Your app is so simple; a backend, a reverse proxy, postgres, and a job runner. So you march on, and add another few sections to your <code>deploy.sh</code> script, certain, that this will be the last of what you need to do to maintain this pile of hacks.</p>
+<p>Ah, but wait! Inevitably, you find a reason to expand to a second server. While it's true <a href="https://news.ycombinator.com/item?id=41340751">a single server can go a long way</a> many things can force this decision, such as the need for special hardware, high availability, or the speed of light. Tired, you parameterize your deploy script and configure firewall rules, distracted from the crucial features you should be working on and shipping. One of your team members suggests connecting the servers with Tailscale: an overlay network with service discovery. After that you will know, yes know, that there is no tougher complexity hurdle to clear than the networking.</p>
+<p>Except if you quit or go on vacation, who will maintain this custom pile of shell scripts? The untested tarball handling? The inscrutable iptables rules? Who will know about those undocumented sysctl edits you made on the VM? So you add everything to Ansible, so that you may treat your VM as immutable and version-controlled. Certain, of course, that because you’re not using Kubernetes, it is going to be way easier to maintain than a Kubernetes cluster. What glorious engineering, you say to yourself.</p>
+<p>In the last leg of your journey to avoid building a Kubernetes, your manager tells you that your app needs to programmatically spawn other containers. Spawning containers, of course, requires you to mount the Docker socket in your web app, which is wildly insecure. Not my problem, your manager says. So you write a separate service that exposes a safe subset of the Docker API to your web app. Done at last, you say to yourself, without having to build a Kubernetes.</p>
+<p>A standard config format, a deployment method, an overlay network, service discovery, immutable nodes, and an API server. Dear friend, you have built a Kubernetes.</p>
+<p><em>Addressed to,</em></p>
+<p><em>Those who did not want to build a Kubernetes.</em></p>
+
+    </div>
+</article>
+
+        </main>
+        
+        <footer>
+            
+    <div class="border"></div>
+    <div class="footer">
+        <div>
+            <a href="/">Home</a>
+        </div>
+        <p xmlns:cc="http://creativecommons.org/ns#">This work is licensed under <a
+                href="https://creativecommons.org/licenses/by-sa/4.0/" target="_blank"
+                rel="license noopener noreferrer">CC BY-SA 4.0</a></p>
+    </div>
+
+        </footer>
+    
+        </div>
+    </body>
+</html>
diff --git a/blog/atom.xml b/blog/atom.xml
index 04011d1..241bf42 100644
--- a/blog/atom.xml
+++ b/blog/atom.xml
@@ -5,8 +5,37 @@
     <link rel="self" type="application/atom+xml" href="https://www.macchaffee.com/blog/atom.xml"/>
     <link rel="alternate" type="text/html" href="https://www.macchaffee.com/blog"/>
     <generator uri="https://www.getzola.org/">Zola</generator>
-    <updated>2024-11-12T00:00:00+00:00</updated>
+    <updated>2024-11-23T00:00:00+00:00</updated>
     <id>https://www.macchaffee.com/blog/atom.xml</id>
+    <entry xml:lang="en">
+        <title>Dear friend, you have built a Kubernetes</title>
+        <published>2024-11-23T00:00:00+00:00</published>
+        <updated>2024-11-23T00:00:00+00:00</updated>
+        
+        <author>
+          <name>
+            
+              Mac
+            
+          </name>
+        </author>
+        
+        <link rel="alternate" type="text/html" href="https://www.macchaffee.com/blog/2024/you-have-built-a-kubernetes/"/>
+        <id>https://www.macchaffee.com/blog/2024/you-have-built-a-kubernetes/</id>
+        
+        <content type="html" xml:base="https://www.macchaffee.com/blog/2024/you-have-built-a-kubernetes/">&lt;p&gt;&lt;em&gt;This post will make more sense if you first read &lt;a href=&quot;https:&#x2F;&#x2F;rachit.pl&#x2F;post&#x2F;you-have-built-a-compiler&#x2F;&quot;&gt;Dear Sir, You Have Built a Compiler&lt;&#x2F;a&gt;.&lt;&#x2F;em&gt;&lt;&#x2F;p&gt;
+&lt;p&gt;Dear friend,&lt;&#x2F;p&gt;
+&lt;p&gt;I am afraid to inform you that you have built a Kubernetes. I know you wanted to &quot;choose boring tech&quot; to just run some containers. You said that &quot;Kubernetes is overkill&quot; and &quot;it&#x27;s just way too complex for a simple task&quot; and yet, six months later, you have pile of shell scripts that do not work—breaking every time there&#x27;s a slight shift in the winds of production.&lt;&#x2F;p&gt;
+&lt;p&gt;Surely, switching to Docker Compose will be the end of your woes; at least that way, someone else maintains a standard config file format for you to use. But wait, Compose is still &lt;a href=&quot;https:&#x2F;&#x2F;www.macchaffee.com&#x2F;blog&#x2F;2024&#x2F;docker-compose&#x2F;&quot;&gt;not a holistic solution&lt;&#x2F;a&gt;. &quot;Do I really need a separate solution for deployment, rolling updates, rollbacks, and scaling?&quot; you ask yourself? Surely not. Your app is so simple; a backend, a reverse proxy, postgres, and a job runner. So you march on, and add another few sections to your &lt;code&gt;deploy.sh&lt;&#x2F;code&gt; script, certain, that this will be the last of what you need to do to maintain this pile of hacks.&lt;&#x2F;p&gt;
+&lt;p&gt;Ah, but wait! Inevitably, you find a reason to expand to a second server. While it&#x27;s true &lt;a href=&quot;https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41340751&quot;&gt;a single server can go a long way&lt;&#x2F;a&gt; many things can force this decision, such as the need for special hardware, high availability, or the speed of light. Tired, you parameterize your deploy script and configure firewall rules, distracted from the crucial features you should be working on and shipping. One of your team members suggests connecting the servers with Tailscale: an overlay network with service discovery. After that you will know, yes know, that there is no tougher complexity hurdle to clear than the networking.&lt;&#x2F;p&gt;
+&lt;p&gt;Except if you quit or go on vacation, who will maintain this custom pile of shell scripts? The untested tarball handling? The inscrutable iptables rules? Who will know about those undocumented sysctl edits you made on the VM? So you add everything to Ansible, so that you may treat your VM as immutable and version-controlled. Certain, of course, that because you’re not using Kubernetes, it is going to be way easier to maintain than a Kubernetes cluster. What glorious engineering, you say to yourself.&lt;&#x2F;p&gt;
+&lt;p&gt;In the last leg of your journey to avoid building a Kubernetes, your manager tells you that your app needs to programmatically spawn other containers. Spawning containers, of course, requires you to mount the Docker socket in your web app, which is wildly insecure. Not my problem, your manager says. So you write a separate service that exposes a safe subset of the Docker API to your web app. Done at last, you say to yourself, without having to build a Kubernetes.&lt;&#x2F;p&gt;
+&lt;p&gt;A standard config format, a deployment method, an overlay network, service discovery, immutable nodes, and an API server. Dear friend, you have built a Kubernetes.&lt;&#x2F;p&gt;
+&lt;p&gt;&lt;em&gt;Addressed to,&lt;&#x2F;em&gt;&lt;&#x2F;p&gt;
+&lt;p&gt;&lt;em&gt;Those who did not want to build a Kubernetes.&lt;&#x2F;em&gt;&lt;&#x2F;p&gt;
+</content>
+        
+    </entry>
     <entry xml:lang="en">
         <title>Flouting the Internet Protocols with Tunnels</title>
         <published>2024-11-12T00:00:00+00:00</published>
diff --git a/blog/index.html b/blog/index.html
index 9e255ce..0807181 100644
--- a/blog/index.html
+++ b/blog/index.html
@@ -103,6 +103,12 @@ <h1>Index</h1>
                     
                     <ul>
                         
+                        <li>
+                        <a href="https://www.macchaffee.com/blog/2024/you-have-built-a-kubernetes/">
+                            Dear friend, you have built a Kubernetes
+                        </a>
+                        </li>
+                        
                         <li>
                         <a href="https://www.macchaffee.com/blog/2024/tunneling/">
                             Flouting the Internet Protocols with Tunnels
diff --git a/blog/sitemap.xml b/blog/sitemap.xml
index 127c3eb..484732b 100644
--- a/blog/sitemap.xml
+++ b/blog/sitemap.xml
@@ -86,4 +86,8 @@
         <loc>https://www.macchaffee.com/blog/2024/tunneling/</loc>
         <lastmod>2024-11-12</lastmod>
     </url>
+    <url>
+        <loc>https://www.macchaffee.com/blog/2024/you-have-built-a-kubernetes/</loc>
+        <lastmod>2024-11-23</lastmod>
+    </url>
 </urlset>
diff --git a/blog_zola/content/2024/2024-11-23-you-have-built-a-kubernetes.md b/blog_zola/content/2024/2024-11-23-you-have-built-a-kubernetes.md
new file mode 100644
index 0000000..2c3f402
--- /dev/null
+++ b/blog_zola/content/2024/2024-11-23-you-have-built-a-kubernetes.md
@@ -0,0 +1,23 @@
++++
+title = "Dear friend, you have built a Kubernetes"
++++
+
+_This post will make more sense if you first read [Dear Sir, You Have Built a Compiler](https://rachit.pl/post/you-have-built-a-compiler/)._
+
+Dear friend,
+
+I am afraid to inform you that you have built a Kubernetes. I know you wanted to "choose boring tech" to just run some containers. You said that "Kubernetes is overkill" and "it's just way too complex for a simple task" and yet, six months later, you have pile of shell scripts that do not work—breaking every time there's a slight shift in the winds of production.
+
+Surely, switching to Docker Compose will be the end of your woes; at least that way, someone else maintains a standard config file format for you to use. But wait, Compose is still [not a holistic solution](@/2024/2024-01-20-docker-compose.md). "Do I really need a separate solution for deployment, rolling updates, rollbacks, and scaling?" you ask yourself? Surely not. Your app is so simple; a backend, a reverse proxy, postgres, and a job runner. So you march on, and add another few sections to your `deploy.sh` script, certain, that this will be the last of what you need to do to maintain this pile of hacks.
+
+Ah, but wait! Inevitably, you find a reason to expand to a second server. While it's true [a single server can go a long way](https://news.ycombinator.com/item?id=41340751) many things can force this decision, such as the need for special hardware, high availability, or the speed of light. Tired, you parameterize your deploy script and configure firewall rules, distracted from the crucial features you should be working on and shipping. One of your team members suggests connecting the servers with Tailscale: an overlay network with service discovery. After that you will know, yes know, that there is no tougher complexity hurdle to clear than the networking.
+
+Except if you quit or go on vacation, who will maintain this custom pile of shell scripts? The untested tarball handling? The inscrutable iptables rules? Who will know about those undocumented sysctl edits you made on the VM? So you add everything to Ansible, so that you may treat your VM as immutable and version-controlled. Certain, of course, that because you’re not using Kubernetes, it is going to be way easier to maintain than a Kubernetes cluster. What glorious engineering, you say to yourself.
+
+In the last leg of your journey to avoid building a Kubernetes, your manager tells you that your app needs to programmatically spawn other containers. Spawning containers, of course, requires you to mount the Docker socket in your web app, which is wildly insecure. Not my problem, your manager says. So you write a separate service that exposes a safe subset of the Docker API to your web app. Done at last, you say to yourself, without having to build a Kubernetes.
+
+A standard config format, a deployment method, an overlay network, service discovery, immutable nodes, and an API server. Dear friend, you have built a Kubernetes.
+
+_Addressed to,_
+
+_Those who did not want to build a Kubernetes._
