Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Seconding K3s being a good option, supports most distros and is easy to set up in minutes: https://k3s.io/
If you'd like to use a management UI instead of just the CLI, Portainer is also a wonderfully lightweight option: https://www.portainer.io/ (and also supports Docker Swarm, if you'd like even more lightweight container orchestration)
That said, in my eyes the biggest problem with Kubernetes is that some distros by default reserve resources and thus disallow overcommit, which is fine from a stability perspective, but doesn't really work for overcommit scenarios.
For example, with Docker Swarm, it's exceedingly easy to say: "Okay, this PostgreSQL instance can use anywhere from 0 to 256 MB of RAM, but no more than that" and with 1 GB of RAM i could easily run 8 of those instances if the average usage was half or less of this maximum limit - a risk that i'd sometimes like to take, when i know that the limits in place are more along the lines of controls so that the whole OS doesn't run into OOM errors.
Of course, if you mess around with the YAML, i guess that's doable on some level as well.
Here’s a comment summarizing the official rationale: https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
TBH, I don’t find those arguments convincing, but then, WebGPU is largely a political compromise, not a technical one. In a politics-free zone, they’d have standardized a “WebVulkan”, not made an entirely new thing. That would have been on the table, but Apple vetoed it. The same for a “Web-SPIR-V”.
However, I also don’t think it’s that big of a deal in the grand scheme of things. I’m glad we have a viable standard at all.
> Kubernetes could run webassembly packages in addition to container images.
https://github.com/krustlet/krustlet
https://cloudblogs.microsoft.com/opensource/2020/04/07/annou...
“Despite the excitement about Wasm and WASI, it should be clear that containers are the major workload in K8s, and for good reason. No one will be replacing the vast majority of their workloads with WebAssembly. Our usage so far makes this clear. Do not be confused by having more tools at your disposal.”
> But, in WebAssembly you get a few more things. One is fast start.
This is one of the key things I think is differentiating versus the container world. The idea of per-request instantiation is possibly within reach. This is a possible return to a very old, very simple architectural pattern, of cgi-bin! Running a process per request. Which we left because creating processes was expensive. Our new architectures- discussed in this write up- revolve around long running applications, which are compelled upon us for performance reasons. But WebAssembly seems well suited to very fast instantiation of new contexts. It re-opens the possibility that we can have (return to) smaller more discrete chunks of work, safer little units of execution running. We could go back to a Apache HTTPD style prefork world, the very old[1]!
This is part of the gradient we've been walking down, it feels like. VMs -> containers -> lighter weight containers. Returning to finer grained processes.
For anyone interested in a deep dive into some of the super neat systems programming going into making WebAssembly starts/instantiation fast, there's a bunch of active work to reengineer module instantiation, using memfd [2][3]. Really fun to see this getting hashed out.
> * So one answer to the question as initially posed is that no, WebAssembly is not the next Kubernetes; that next thing is waiting to be built, though I know of a few organizations that have started already.*
And as others have recommended, worth noting Krustlet[4], which allows running WebAssembly instances via Kubernetes. This could definitely make sense for a lot of our workloads. I think a lot of people also expect though that the cloud infrastructure itself will get rewritten or recompiled into webassembly. Where-as today we tend to wire systems together over protocols, via http or grpc, we'll be able to more directly stitch together plugably modular systems, where a generic control process to govern, i dunno pick an example, load balancers say, has a bunch of specific webassembly modules plugged in with the specific actuators / configuration for your set up. There's a real potential to fulfill much of the idea of micro-kernels here, of decomposing big applications into looser assemblages of generic code, drivers, and configuration.
[1] https://httpd.apache.org/docs/2.4/misc/perf-tuning.html#comp...
[1] https://github.com/bytecodealliance/wasmtime/pull/3697
[2] https://github.com/bytecodealliance/wasmtime/pull/3691
[3] https://krustlet.dev/
Does anyone have any examples of a sort of self hosted way to do functions as a service with web assembly? I know you can do web assembly FaaS with Cloudflare Workers (https://github.com/cloudflare/workers-rs among others) but am unaware of a way to self host.
That would indeed be super useful to extend self hosted automation tools like Huginn. From what I understand, wasm/wasi modules don't have full networking or filesystem access support yet. So you probably have to rely on specific runtimes to provide hooks for doing that, and regular code won't work out of the box.
1. https://github.com/suborbital/reactr
Seconding K3s being a good option, supports most distros and is easy to set up in minutes: https://k3s.io/
If you'd like to use a management UI instead of just the CLI, Portainer is also a wonderfully lightweight option: https://www.portainer.io/ (and also supports Docker Swarm, if you'd like even more lightweight container orchestration)
That said, in my eyes the biggest problem with Kubernetes is that some distros by default reserve resources and thus disallow overcommit, which is fine from a stability perspective, but doesn't really work for overcommit scenarios.
For example, with Docker Swarm, it's exceedingly easy to say: "Okay, this PostgreSQL instance can use anywhere from 0 to 256 MB of RAM, but no more than that" and with 1 GB of RAM i could easily run 8 of those instances if the average usage was half or less of this maximum limit - a risk that i'd sometimes like to take, when i know that the limits in place are more along the lines of controls so that the whole OS doesn't run into OOM errors.
Of course, if you mess around with the YAML, i guess that's doable on some level as well.
The parallels between WASM and the JVM are well known. But I like to think of it as WASM is building upon the knowledge gained from the JVM.
With the JVM you had to reimplement your language to target it, or design a new one. WASM was planned from the start to be a target for existing compiler frameworks such as LLVM and GCC.
With Jython you could not use extension that were designed for CPython. With WASM you can. Take a look at Pyodide, they have ported most of the scientific Python stack to WASM, that’s not possible with Jython.
https://github.com/pyodide/pyodide
> This post describes something like Erlang actors, but if each can be a pure function encoded in WASM...
Not just a dream. https://github.com/fluencelabs/fluence
Interesting that this subject came up today. A few days ago I was looking back at Capsicum [1], a project meant to bring a capabilities framework to UNIX I knew about from years back. The impetus behind it being a short review of containerization primitives I was going about. Sadly it doesn't seem Capsicum went anywhere in Linux-land beyond kernel patches. But one of the subsequent project that pages on Capsicum often pointed to is the WebAssembly System Interface [2]. POSIX APIs, capabilities and portability sounds strangely apt for microservices, but at this point I'm still not too sure how to think about it. I'd appreciate it if anyone had good WASM/ASI resources for stupid devs like me.
[1]: https://www.cl.cam.ac.uk/research/security/capsicum/
[2]: https://wasi.dev
I'll ask the same questions I had over on lobsters since I didn't get satisfactory answers there:
* 64bit - Can I run a database that addresses more than 4 gig of memory (eg: keep all my indices in memory so perf doesn't fall off a cliff)? I think the answer is no. This effectively rules out most 'enterprise' software and most things involving 'big data' (eg: all ai/ml projects), not to mention I haven't deployed 32bit to prod in something like 10 years.
* threads - shared array buffers && web workers aren't threads - this isn't the biggest deal in the world since all interpreted languages are effectively single process/single thread but there is quite a lot of software that would like real threads.
* security - You can overwrite constants in what traditionally would be read-only. You can overwrite portions of the stack. You can overwrite the heap. You can overwrite function pointers. You can overwrite and redirect indirect calls. Taking an existing linux binary and converting it to wasm severely downgrades the security of it.
* real sockets/TLS - https://github.com/WebAssembly/WASI/pull/312 && https://github.com/bytecodealliance/wasmtime/issues/71 ? yes, I understand some people have shimmed in various layers here but most applications would currently require modification to use said shims - what's the best of breed to not require application mods?
If I recall correctly, Saša Jurić mentioned in an interview that he envisions the BEAM being used as an OS in the future, where you can run your database, web server and other services under one VM.
While I don't personally have much use for it (at the moment), I'm curious about how this would look like with Lumen [0] where you can run your whole web stack with a single binary and being internally supervised by the BEAM.
Lumen's development has been slow but I remember seeing a tweet from a team member stating that development is slowly ramping back up (not a criticism in any way, just providing some context).
[0] https://github.com/lumen/lumen
There is a proposal from Mozilla/Facebook for a binary JS format.
https://github.com/tc39/proposal-binary-ast