Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

The amount of vitriol in this comments section is astonishing. Can we not share fun projects without the professional Kubernetes experts thumbing their noses? At the very least, it does seem now like the complexity of K8s’s code base is a point of very thin skin for the community.

This is ~17k lines of shell scripting and claims to be &quot;simple&quot;. Kuberentes is probably ~1m lines of Go. I&#x27;m not entirely convinced that this is less complex (simpler) than Kubernetes.<p>There are many factors in complexity, but a big one for me is what I have to hold in my head – global state. From any given point, what do I need to understand to know what&#x27;s actually going on.<p>For Go, this is actually comparatively little. Between a fairly straightforward language, static binaries, and the focus on ease of distribution, there&#x27;s not a whole lot outside of a codebase itself to think about.<p>However for a shell like Bash there&#x27;s a relatively large amount to consider. You&#x27;re very exposed to the underlying OS, to libraries and system packages, to various tools, to configurations users may have specified, to things being redefined underneath you. There&#x27;s a lot of global state to consider for a Bash script.<p>I suspect it is simpler than Kubernetes, but I don&#x27;t think it&#x27;s a clear cut case.

&gt; simple<p>&gt; 17k lines of shell script<p>those two phrases don&#x27;t belong together... to think about this, &quot;17k lines&quot; and &quot;shell script&quot; should not be used together either.<p>Also, you are a bit light on tests.. there only seems to be a single trivial one, which seems way too low for a codebase this size.

Building a platform to deploy stateless services are the easy part. This might even work nicely at a smaller scale. It is gets super complicated when you want to mount volumes, re-use those volumes. This is like a nice weekend project, contrarian in nature, but it is just not a replacement for kubernetes. This is some bash script orchestration on top of podman.<p>Bulk of complexity in opensource distro of kubernetes comes from the fact that everything is interface driven and has to work in an generic way. For example, you don&#x27;t really have to implement cri-o like thing if you are opinionated platform and only supports docker. Similarly, you don&#x27;t have to build CSI, if you only support ceph or aws&#x27; storage. I love the contrarian thought, but matter of the fact is modern orchestration platforms that want to be a general purpose platform is going to be big.<p>It is a really nice exercise however build something like this when you want to learn about networking, containers, orchestration, storage etc. and how to tied everything together.

This is my kind of tom foolery. Love it. You should come work with me at Heroku: <a href="https:&#x2F;&#x2F;www.heroku.com&#x2F;careers&#x2F;software-engineer-heroku-runtime-infrastructure-102" rel="nofollow">https:&#x2F;&#x2F;www.heroku.com&#x2F;careers&#x2F;software-engineer-heroku-runt...</a>

Software developers should be required to have a license to use the word &quot;simple&quot;.

Kubernetes might follow the sad path of spring.<p>Perfect, complete and too complex.<p>For big and great applications, spring if the obvious choice. It makes incredible complex and difficult things easy.<p>But, unfortunately, makes simple and quick applications incredible complex and difficult.

i love this, and especially love how there are only a few things in the world that one could reasonably claim to simplify with &quot;17k lines of shell script&quot;, and one of those is kubernetes. hilarious! (and i even see the value beyond the mere humor of the project&#x27;s existence, which for me (and unlike all these salty k8s stan commenters*) would be <i>more</i> than enough justification on its own for creating the project in the first place). it&#x27;s like both a useful project and performance art!<p>* for the umpteenth time i daresay that hn needs to grow a sense of humor sometimes...

17k lines is a lot of shell... but... it bypasses all the complexity of heavyweight scripting languages, bash is a lightweight interpreter that is always there and just works and i bet it&#x27;s fast.<p>this is a cool idea.<p>next up, somebody will modernize daemontools for the container&#x2F;cluster era...

If you&#x27;re looking for a simple Kubernetes alternative, take a look at the HasiCorp stack. I use that in production and it&#x27;s easy to set up and maintain.

1. Anything that offers effective competition to Kubernetes is a Good Thing. I&#x27;m not saying this is because I haven&#x27;t look at it closely enough but competition brings about improvement.<p>2. Why do people write &quot;Simplenetes has a 100x less code than Kubernetes&quot; instead of saying it has 1&#x2F;100th the code?

I’m not sure if rewriting applications in bash should be considered an improvement... <a href="https:&#x2F;&#x2F;twitter.com&#x2F;astarasikov&#x2F;status&#x2F;568825996532707330?s=21" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;astarasikov&#x2F;status&#x2F;568825996532707330?s=...</a>

Unsolicited review of sync.sh ahoy!<p>The easy stuff:<p>- Non-exported variables are by convention lower_case, while exported variables are UPPER_CASE.<p>- Function names are by convention lower_case.<p>- There&#x27;s a &quot;quite&quot; signature string and variable; should it be &quot;quiet&quot;?<p>- The lines like `local hosts=` can be simplified as `local hosts`. You can also join such lines, as with `export`, into `local foo bar baz …`.<p>- `[[` is generally considered more reliable than `[` (there are a bunch of posts about this on Stack Overflow and Unix Stack Exchange).<p>- Naming scripts .bash rather than .sh lets `shellcheck` inspect them without telling it which shell to verify against. You do check these files using `shellcheck`, right?<p>- Variable names like `list` and `tuple` are unhelpful; what do they actually contain? Also, they should probably be actual arrays rather than a space-separated string to avoid relying on word splitting, and to allow entries with whitespace in them.<p>The scary stuff:<p>- All the string packing and unpacking also makes me nervous. That&#x27;s not simpler than using JSON&#x2F;YAML, it&#x27;s just a different kind of complexity.<p>- Reusing the same variable a bunch of times in the same function makes it really easy to end up with the wrong value at some point. Better to split stuff into more functions or rename the variables to make them single use.<p>- `set -o errexit -o pipefail` would be good to have for safety.<p>- `kill -9` anything[1]<p>- Why are some of the variables inside functions not local? They effectively end up being globals, which makes for really difficult debugging.<p>The good stuff:<p>- Using local variables everywhere.<p>- Descriptive error messages.<p>- Returning early in case of errors.<p>All in all, Bash is not a good language for any system of this size, no matter how diligently you program. The error handling isn&#x27;t comparable to most mainstream languages, the data types are incredibly limited, and there&#x27;s no native support of recursive languages like JSON. You&#x27;ve done a great job, but I&#x27;m afraid a system like this is doomed to failure from these facts alone.<p><pre><code> [1] https:&#x2F;&#x2F;mywiki.wooledge.org&#x2F;ProcessManagement#I.27m_trying_to_kill_-9_my_job_but_blah_blah_blah...</code></pre>

Not April fools judging by github history...

This is really cool, but is there a real use case for this?

Wait, he writes insane shell scripts, and his Twitter handle is BASH-lund?<p>I&#x27;m in love! &lt;3 :-D<p>Related: Bocker, Docker rewritten in 100 lines of Bash <a href="https:&#x2F;&#x2F;github.com&#x2F;p8952&#x2F;bocker" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;p8952&#x2F;bocker</a>

No Persistent Volume support, so not great for stateful applications. Claims that type of thing is &quot;magic&quot;, and therefore out of scope.<p>Quite an engineering feat, though, I am sure! Is this to have fun, to learn, to actually use in production?

Im personally not ever gonna use it as long as docker swarm is maintained.<p>But thank you for bringing the world another tiny step closer to abandoning k8s and k8s (over-engineering) mentality.<p>You’re doing so much for the world and for all the developers. Thank you!

This has been bugging me for a while. Programmers <i>love</i> to reinvent the wheel. There a millions of make(1) clones, key-value stores, etc but I don&#x27;t seem to see many projects (even toys) in the &quot;declarative container runners&quot; space. I think it&#x27;s a shame.<p>While Kubernetes is hopefully Very Good, it is complicated, and I have often wondered what other approaches would yield (e.g. more imperative ones, because writing admission controllers is not exactly easy). So I&#x27;m glad to see people playing around, though I don&#x27;t know if this amount of bash is healthy or if 17,000 lines is simple.

Languages: Shell 100.0%<p>Impressive

At some point, April Fools jokes ceased being funny.<p>Now I’m trying to figure out if I just got too old to appreciate them, or if the good ones have all been used up.

<p><pre><code> - No magic involved </code></pre> says the one with a single file 13k LoC shell script.

<p><pre><code> -q Set to be quite. </code></pre> I doubt it&#x27;s intentional, but I kinda love it.

Most of these source code files are very large. Where should I start reading?

Reminds me of a coworker many years ago who wrote a script he called bash-reduce. Turned out not to be so simple in practice ;)

Rewriting anything is the ultimate learning experience and to do a Kubernetes implementation in shell script, impressive.

Love it. Also love how triggered the very serious cloud native HN weenies are about this in the comments.<p>Lighten up folks.

This is so cool. Might be useful for self-hosting a bunch of things on my local network.

What happens if a node fails?

17k lines of shell? Hah give me the infinity lines of Go that is kubernetes — maintaining shell scripts is a nightmare. At least Go is a proper language with an ecosystem and tests and established best practices, etc., etc.<p>Also namespaces are a killer feature of K8s imo

This or something like this is very much needed

great job! looks like a fun project.

No wireless, less space than a Nomad. Lame.

This is a cool idea regardless of being simple or complex. Who cares, its cool.<p>Nice job

Now do this with .bat files :)

If you drop enough feature everything is simpler.

I don’t care about Kubernetes, but someone might read this post and decide that it is a good idea to “simplify” an existing project by rewriting it in 17000 lines bash script.<p>And some hapless person will be stuck maintaining and debugging it. It could be me, or you, your friend. You don’t want this to happen.

This seems like a huge waste of time and effort. I can only hope that it an april fools joke.

tbf the maintainer of Simplenetes throws an incredible amount of shade against Kubernetes

The whole setup of github project looks like it is a serious attempt.