Skip to content

Commit

Permalink
Add you-have-built post
Browse files Browse the repository at this point in the history
  • Loading branch information
mac-chaffee committed Nov 24, 2024
1 parent 9839d9a commit f001c85
Show file tree
Hide file tree
Showing 6 changed files with 204 additions and 1 deletion.
6 changes: 6 additions & 0 deletions blog/2024/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
135 changes: 135 additions & 0 deletions blog/2024/you-have-built-a-kubernetes/index.html
Original file line number Diff line number Diff line change
@@ -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>
31 changes: 30 additions & 1 deletion blog/atom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down
6 changes: 6 additions & 0 deletions blog/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 4 additions & 0 deletions blog/sitemap.xml
Original file line number Diff line number Diff line change
Expand Up @@ -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>
23 changes: 23 additions & 0 deletions blog_zola/content/2024/2024-11-23-you-have-built-a-kubernetes.md
Original file line number Diff line number Diff line change
@@ -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._

0 comments on commit f001c85

Please sign in to comment.