WebAssembly: The New Kubernetes?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • SaaSHub - Software Alternatives and Reviews
  • k3s

    Lightweight Kubernetes

    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.

  • gpuweb

    Where the GPU for the Web work happens!

    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.

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • krustlet

    Kubernetes Rust Kubelet

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

  • wasmtime

    Standalone JIT-style runtime for WebAssembly, using Cranelift

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

  • workers-rs

    Write Cloudflare Workers in 100% Rust via WebAssembly

    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.

  • hive

    Function scheduler for Go & WebAssembly (by suborbital)

    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

  • Portainer

    Making Docker and Kubernetes management easy.

    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.

  • SonarLint

    Deliver Cleaner and Safer Code - Right in Your IDE of Choice!. SonarLint is a free and open source IDE extension that identifies and catches bugs and vulnerabilities as you code, directly in the IDE. Install from your favorite IDE marketplace today.

  • pyodide

    Pyodide is a Python distribution for the browser and Node.js based on WebAssembly

    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

  • fluence

    Peer-to-peer computing protocol and licensing system (by fluencelabs)

    > 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

  • wasi-libc

    WASI libc implementation for WebAssembly

    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

  • wasm-micro-runtime

    WebAssembly Micro Runtime (WAMR)

  • WASI

    WebAssembly System Interface

    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?

  • lumen

    An alternative BEAM implementation, designed for WebAssembly (by lumen)

    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

  • proposal-binary-ast

    Binary AST proposal for ECMAScript

    There is a proposal from Mozilla/Facebook for a binary JS format.

    https://github.com/tc39/proposal-binary-ast

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts