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

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's actually going on.

For Go, this is actually comparatively little. Between a fairly straightforward language, static binaries, and the focus on ease of distribution, there's not a whole lot outside of a codebase itself to think about.

However for a shell like Bash there's a relatively large amount to consider. You'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's a lot of global state to consider for a Bash script.

I suspect it is simpler than Kubernetes, but I don't think it's a clear cut case.

> 17k lines of shell script

those two phrases don't belong together... to think about this, "17k lines" and "shell script" should not be used together either.

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.

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't really have to implement cri-o like thing if you are opinionated platform and only supports docker. Similarly, you don't have to build CSI, if you only support ceph or aws' 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.

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.

Perfect, complete and too complex.

For big and great applications, spring if the obvious choice. It makes incredible complex and difficult things easy.

But, unfortunately, makes simple and quick applications incredible complex and difficult.

* for the umpteenth time i daresay that hn needs to grow a sense of humor sometimes...

this is a cool idea.

next up, somebody will modernize daemontools for the container/cluster era...

2. Why do people write "Simplenetes has a 100x less code than Kubernetes" instead of saying it has 1/100th the code?

The easy stuff:

- Non-exported variables are by convention lower_case, while exported variables are UPPER_CASE.

- Function names are by convention lower_case.

- There's a "quite" signature string and variable; should it be "quiet"?

- 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 …`.

- `[[` is generally considered more reliable than `[` (there are a bunch of posts about this on Stack Overflow and Unix Stack Exchange).

- 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?

- 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.

The scary stuff:

- All the string packing and unpacking also makes me nervous. That's not simpler than using JSON/YAML, it's just a different kind of complexity.

- 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.

- `set -o errexit -o pipefail` would be good to have for safety.

- `kill -9` anything[1]

- Why are some of the variables inside functions not local? They effectively end up being globals, which makes for really difficult debugging.

The good stuff:

- Using local variables everywhere.

- Descriptive error messages.

- Returning early in case of errors.

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't comparable to most mainstream languages, the data types are incredibly limited, and there's no native support of recursive languages like JSON. You've done a great job, but I'm afraid a system like this is doomed to failure from these facts alone.

  [1] https://mywiki.wooledge.org/ProcessManagement#I.27m_trying_to_kill_-9_my_job_but_blah_blah_blah...

I'm in love! <3 :-D

Related: Bocker, Docker rewritten in 100 lines of Bash https://github.com/p8952/bocker

Quite an engineering feat, though, I am sure! Is this to have fun, to learn, to actually use in production?

But thank you for bringing the world another tiny step closer to abandoning k8s and k8s (over-engineering) mentality.

You’re doing so much for the world and for all the developers. Thank you!

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'm glad to see people playing around, though I don't know if this amount of bash is healthy or if 17,000 lines is simple.

Impressive

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.

    - No magic involved

    -q Set to be quite.

Lighten up folks.

Also namespaces are a killer feature of K8s imo

Nice job

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.