Show HN: Kubernates in Node.js
github.com
This project was/is an attempt to recreate the core functionality of v1.29.1 Kubernetes in NodeJS, while being fully compatible with the kubectl CLI.
github.com
As a concrete example, command: ["bash -c uptime"] will not work because there is no such command '/usr/bin/bash -c uptime' and the actual form is command: ["bash", "-c", "uptime"]
Related, it often bites people that exec does no shell interpolation, neither resolving variables nor redirection, so command: ["doit", ">/dev/null"] will not shake out, nor will command: ["echo", "$HOSTNAME"] (although there is a nuance to that since kubernetes itself will actually resolve any env:[] references in a (regrettably horrible) syntax of command: ["echo", "$(USERNAME)"], env: [{name: USERNAME, value: megapixel99}]
All in all, congratulations on your Show HN!
Regardless, thank you for the feedback.
If you ever feel inspired to do so, I *really* wish somebody would write a decent way to do controllers in JS rather than golang (metacontroller is a lovely idea but somewhat limited in what you can build with it).
Full disclosure I haven’t tried this but I’m curious if you have. The main component of a controller is its k8s client, so go will always have an advantage, but this JS client looks somewhat decently maintained
Muchas gracias and I'll have to have a look next time I'm in a suitably masochistic mood for k8s hackery.
It's a shame that this is an exact copy in a different language.
Kubernetes is nice but I can't wait to see what the next generation of tools will look like.
Sadly, it's no longer being developed as of 3-4y ago.
Maybe in the future I will create something that could be a competitor.
It’s called “lattice”, and it’s a software architecture with similar intentions as Kubernetes, but a vanilla approach that leans into existing frameworks instead of inventing things from scratch
I introduced Docker Swarm at work in 2018 and already there were rumours that since Kubernetes had won it was just a matter of time until Docker Swarm was fully abandoned.
How likely do you think the introduction of a nodes primitive is given this?
I can see it if it were a strict opt in addition but it feels like it also fundamentally expands the scope of what the tool is.
Kubernetes in Rust: Straight to the top
Usually for bad reasons like a false dichotomy between SQL & NoSQL (you usually want both) or some performance comment about JS when they're using like a Rails, Django, or Laravel (some old/slow cult framework that doesn't hold a candle to Node).
Feels like Rust found its place with Next.js' Turbopack (basically Webpack but in Rust), and is good for use cases like that. I think reinventing wheels in other languages makes sense when they bring obvious value like performance or some convenience - and this Show HN fits that description.
Like someone else said - it might've been even cooler as not a re-write but a new approach in Node.
I would love to see Node eat more of Linux personally. To me JavaScript is like the "English" of programming (C is "Latin"?), with JSON being the standard transfer format and the browser being a major (if not the major) platform. Not to mention it's by far the most performant of the dynamic web languages (compared with PHP, Ruby, Python).
1. Speed: NoSQL is way faster than SQL for most access
2. Ease: Dev time is lower as the data is kept in the way you'll use it, not in relational tables - skip the ORM, skip the db migrations, etc.
3. You need NoSQL at scale anyway: As the sole db of an app, NoSQL isn't ideal at scale because of data duplication and storage size. But when/if you need to add SQL you probably still keep the NoSQL too for the faster access, storing temp data, etc. Most companies use both SQL and NoSQL.
Scenario:
Imagine an API for a video game that fetches data for an Auction House type feature. If every single time your millions of players were running SQL queries, it would be an incredibly slow and expensive feature. Much better to have that data cached in a NoSQL layer so people can access it quickly/concurrently, and only periodically hit SQL to populate out NoSQL caches. Could also use an ORM with SQL, or another in-memory solution, but NoSQL is nice if there are many nodes or maybe due to your cloud setup you can't run it in memory.
Really is not a "SQL vs NoSQL" you use both for different things. To me at this point it doesn't matter if someone "starts with" SQL or NoSQL, in almost all cases I would use both eventually. For hobby projects, even a slight preference toward NoSQL for ease of use and data flexibility, but getting into subjective territory. Sequelize is just as cool/easy
I find NoSQL document databases harder to maintain over time, and you can always have tables with JSON columns.
But moreover, my question was about MongoDB, not about SQL vs NoSQL. And it has been answered, the developer was familiar with it.
Very true with maintainability - it's ridiculous to use a NoSQL as your main db eventually because of duplicate data and the very large file storage.
You'd use neither of them with certain math or AI (they use vector dbs optimized for array data) - different tools/jobs.
Not that I would do the same, but I can understand to some degree.