I've been using goja in a logical replication tool to make it field-programmable by the end users. No two deployments look alike, so a great deal of flexibility is needed for ETL uses. There's a tendency for configuration languages to become Turing-complete, so we started with a Turing-complete language for configuration.
JS, or in Replicator's case, TypeScript (shout-out to esbuild), is sufficiently well-known that any dev group will have some experience with it. On the whole, I've been very impressed with how straightforward it's been to have user-scripts integrated into the processing pipeline.
In a word: bokeh. I'm running a 50mm f/1.8 lens on a full-frame sensor. My job requires me to interact with external customers, sometimes in a pre-sales role. Appearances shouldn't matter, but they do. Anything I can use to present a more professional and "expert" image is a win for me.
Switching to a "real" camera has been such a huge, huge improvement for me on video calls all day, I machined a custom vesa mounting arm to hold my camera in just the right spot.
(Cockroach Labs developer here) In CockroachDB parlance, a "cluster" is just some number of cockroach binaries that have local storage and can connect to one another via TCP/IP. It's entirely feasible to run a multi-node cluster on a single laptop by just starting several instances of cockroach bound to different port numbers.
The Kubernetes concept of a "cluster" is a much broader term, encompassing the compute nodes and a lot of control-plane software to make all of the magic happen.
Fundamentally, running CockroachDB on a Kubernetes cluster abstracts away the process of getting the cockroach binary running and offers a lot of convenience to the human operator vis-a-vis reliability and service discovery.
We like to say that CockroachDB is "Kubernetes native" in that you can easily build a CRDB cluster using only the basic k8s building blocks, without requiring a separate operator program to manage the deployment.
Utilities like Helm et al. are certainly easier than managing a bunch of YAML configs, but they are entirely optional.
Some other CockroachDB+Kubernetes synergies to consider:
1) When using a StatefulSet and PersistentVolumes, a CockroachDB node will easily survive being rescheduled off of its underlying host (e.g. due to maintenance or hardware failure) with no human effort needed.
2) All cockroach instances are, from the perspective of a client, homogenous. That is, a client can send a SQL query to any member of a CockroachDB cluster and get a meaningful response. This maps exactly onto the k8s Service abstraction.
3) Federated k8s clusters and multi-region network fabrics do exist, although they're not exactly common yet. CockroachDB can maintain its clustering across "non-uniform network architectures" that exist within- and cross-region.
JS, or in Replicator's case, TypeScript (shout-out to esbuild), is sufficiently well-known that any dev group will have some experience with it. On the whole, I've been very impressed with how straightforward it's been to have user-scripts integrated into the processing pipeline.
https://github.com/cockroachdb/replicator/wiki/User-Scripts