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.
Seems like my click-baity title brought out some strong feelings :)
I do actually like Kubernetes. I recommend it to clients, I assess candidates who are to work with it, but I do really think it is a Beast. Because it is.
Kubernetes is like C++, extremely useful but it just keeps growing and nobody really knows all of it.
While Simplenetes is like... Lua, batteries not included, your boss will not approve, it doesnt't hit the buzzspot, but some people will secretely use it and be happy about it.
This is ~17k lines of shell scripting and claims to be "simple". Kuberentes is probably ~1m lines of Go. I'm not entirely convinced that this is less complex (simpler) than Kubernetes.
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.
To be fair Kubernetes itself probably has 17k lines of bash, and it is a good thing. It is the first go-to project that I use as a reference for bash scripting best practices.
edit: wc reports 47023 lines in *.sh[1], out of which 23836 are unique[2].
I can't believe you are being serious - why are you comparing a shell script to a million-line piece of production software? Apples to oranges. This was written as a joke to make fun of a common gripe against Kubernetes - its complexity. Seems like the Kubernetes community has a bit of a thin skin.
If it is a joke, the README does a poor job of conveying that. It is a bit funny at first but then gets relatively serious and recommends the project for use with up to 20 containers, with the beta caveat.
Either way, setting aside the laudable amount of work put into this, talking about the issues of complexity and different forms it takes seems quite on topic. (I don't have a cow in this fight, not using K8s or anything of the sort.)
If we take out the argument of OS dependent setup, supporting only stateless services etc.
One of the key benefits of kubernetes are API server and custom resource definitions. If you don't like how kubernetes does stuff. You can change the default behavior and orchestrate the way you want.
i dunno. autotools is hairy, but it also solved some incredibly hairy problems over an enormous breadth for a very long time in a very reliable manner.
portability across all the different unices with their weird c compilers and differing libcs that actually worked out of the box every time was a gargantuan task.
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.
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.
The hate against spring on hacker news is so ridiculous. Spring boot is one of the easiest lowest boilerplate ways to build anything, period. Especially if you use a type dynamic language on top, like groovy or kotlin or whatever.
Some people are just masochistic or they just want to distract themselves by solving problems that have already been solved by Spring circa 10 years ago. Most of them don't even use the technology that they preach around here, it's borderline trolling.
Asking to learn, but if you were to start a Java application in the following two scenarios:
1) Monolith with some CRUD, API, persistence to a DB + search.
2) Scalable backend with an API, persistence to a DB + some caching
I don't disagree with your conclusion. But your comment communicates no argument against Spring and how the trade-offs it makes make it a poor option for new projects.
i love this, and especially love how there are only a few things in the world that one could reasonably claim to simplify with "17k lines of shell script", and one of those is kubernetes. hilarious! (and i even see the value beyond the mere humor of the project's existence, which for me (and unlike all these salty k8s stan commenters*) would be more than enough justification on its own for creating the project in the first place). it's like both a useful project and performance art!
* for the umpteenth time i daresay that hn needs to grow a sense of humor sometimes...
Readit News
Seems like my click-baity title brought out some strong feelings :)
I do actually like Kubernetes. I recommend it to clients, I assess candidates who are to work with it, but I do really think it is a Beast. Because it is.
Kubernetes is like C++, extremely useful but it just keeps growing and nobody really knows all of it.
While Simplenetes is like... Lua, batteries not included, your boss will not approve, it doesnt't hit the buzzspot, but some people will secretely use it and be happy about it.
Deleted Comment
I was thinking why are people talking about virtio so much.
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.
edit: wc reports 47023 lines in *.sh[1], out of which 23836 are unique[2].
[1]: find . -name '*.sh' | xargs cat | wc -l
[2]: find . -name '*.sh' | xargs cat | sort | uniq | wc -l
It can distinguish between actual lines of code, comments and empty lines for a lot of different languages.
Either way, setting aside the laudable amount of work put into this, talking about the issues of complexity and different forms it takes seems quite on topic. (I don't have a cow in this fight, not using K8s or anything of the sort.)
https://caseymuratori.com/blog_0031
I'm not sure you can with shell scripting because of all the global system state.
One of the key benefits of kubernetes are API server and custom resource definitions. If you don't like how kubernetes does stuff. You can change the default behavior and orchestrate the way you want.
> 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.
About the tests, can't disagree with you, they will come.
[1] https://github.com/space-sh/space
portability across all the different unices with their weird c compilers and differing libcs that actually worked out of the box every time was a gargantuan task.
I assumed it was tongue-in-cheek?
Deleted Comment
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.
what would you use these days?
* for the umpteenth time i daresay that hn needs to grow a sense of humor sometimes...