WebAssembly: The New Kubernetes?
wingolog.org
wingolog.org
- Plugins for desktop/mobile apps, wasm provides a nicely sandboxed environment for them.
- Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime.
- Embedded electronics, simplifying the development and deployment of IoT devices.
When it comes to wasm on the server, it’s often talked about as targeting the “edge”. I believe this the next area of massive growth, however the part that I don’t think is fully solved yet is on the database side. If your server app is making multiple database calls from the edge to a central db there is a good chance that it will slower than a traditional (single location) deployment.
What’s needed is a edge first database, we need at least read replicas to be at the edge with your app. Fly.io have something like this with their Postgres’s product. The alternative is to use an eventually consistent db such as CouchBD, but that causes other problems. I’m interested to see if CloudFlare do anything in this area as it’s the part of their stack that’s missing.
OpenGL/WebGL aren’t well enough aligned with modern hardware to serve as a cross-platform graphics layer.
That’s where the newer APIs come in. Vulkan, Metal and DirectX 12 all follow similar principles that would work from a technical standpoint, but we live in an age where platform vendors would rather cripple their platform than make it easy to port software. Apple is the worst offender here, because while Microsoft isn’t happy about it and disables it in “metro” apps, at least they don’t prevent GPU vendors from shipping Vulkan support for normal “desktop” apps.
But I’m optimistic about WebGPU: It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. And it’s low-level enough that it should allow implementing modern games on top of it.
(To clarify: I’m optimistic about WebGPU as an API for desktop applications. For browser apps, it seems like all vendors are on board already.)
Their choice of inventing their own shading language instead of using the ONE standard that the industry finally could agree on (SPIRV) makes me very pessimistic.
Apple is purposefully crippling stuff to retain their App dominance yes, but Apple IS a major part of WebGPU. So it never had a chance and was doomed to fail from the very begining.
Google even had a presentation titled "regaining developer trust" on this topic, but WebGPU continued to push WGSL nevertheless.
I fail to see where your point about trust fits in to that.
The original google proposal was to simply use SPIRV. A compromise was then settled for the intermediary language to be isomorphic to SPIRV, removing some of the warts and edges of it and make verification easier.
However, Apple with the help of the Mozilla folk successfully managed to twist the semantics into something that is no longer easy to translate from and to.
Game developers don't want to work with WSGL, the whole point of the new WASM and WASI ecosystem is to allow devs to bring their own tools.
This is especially bad for something like a shader language, where you want to squeeze every bit of performance out of the hardware, often with hand rolled instructions. Having the browser run a mangled version of the SPIRV that you or your toolchain/engine e.t.c. produced is simply not acceptable.
> Trivially convertable to SPIR-V
> Constructs are defined as normative references to their [SPIR-V] counterparts
> All features in WGSL are directly translatable to [SPIR-V]
> Features and semantics are exactly the ones of [SPIR-V]
> Each item in this spec must provide the mapping to [SPIR-V] for the construct
So WGSL is essentially just an alternative representation for SPIR-V.
But I don't see how this compromises the viability of webgpu.
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.
It's a textbook case of: Embrace, Extend, Extinguish
Google tried to save it, but that proposal was rejected: https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU...
The Proposal to work with both WGSL, was also not accepted because it would "weaken the position of WGSL".
"But think of the children/open web!"
Apple knows how to push the right buttons on the Mozilla folks so that they tag along: Rust, wEB-StAnDARds, not invented here.
- SPIRV was done by an evil technological group, not an open and inclusive standard body. We would tie our standard to whatever the SPRIV says, that's not open web. The open web can only flourish if everything is text based! cough WASM cough Rust ist such a modern language! -
It's similar to what happened to WebSQL, except this time it's much worse as it also ruins any hope that WASM might be able to replace all the other technological cruft. Playing the old guessing game of how the transpiler will mangle your SPIRV is simply not something that people want to go back to.
The draft was just updated two days ago.
Are you saying that the direct mapping requirements I quoted above have been abandoned?
Yes.
See these quotes:
Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too"
...
Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point"
...
Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime."
From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4...
See also:
https://github.com/gpuweb/gpuweb/pull/599
https://github.com/gpuweb/gpuweb/issues/582
https://github.com/gpuweb/gpuweb/issues/566
http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
https://news.ycombinator.com/item?id=24858172
The process has been very implementation driven, with Naga, the Rust tooling that does the whole conversion shenanigans, growing and changing its IR and semantics steadily. It's ironic that a group that is usually very adverse to having a single implementation of things is now pointing to Naga and arguing that we don't need an easy conversion step because we have all the compiler infrastructure build already.
The group has slowly redefined "bijective" to mean "easily compilable", which would be pretty hilarious, if it weren't so sad.
So you now have a platform target with one codebase that developers can target PC/Mac/Linux, mobile/tablet, and one of the biggest console platforms. I'd say that's pretty powerful.
Apple support for OpenGL is a side effect of NeXT's acquisition, had Copland's efforts succeeded, they would have kept using QuickDraw 3D.
Ah, and Google Maps.
Lua, JS and LLV IRM?
Lua and JS are not even binary languages.
LLVM-IR has been considered, but has never been suitable as a compiler target. Code is targeted for a specific arch even before it becomes translated into LLVM-IR. Undefined behaviour in C is undefined also in LLVM-IR, and a portable compiler target can not have any. It is also changing too much between compiler versions (which is a reason why SPIR moved away from it).
BTW. It seems that in the long-term, the use of LLVM-IR in compilers is going to be replaced with MLIR (Multi-level IR).
The future of gaming and the metaverse is cross-platform and free of walled gardens, with developers empowered to distribute directly to their end users online without a middleman required. The reinvention and subsequent golden age of high fidelity 3D browser games will be upon us sooner than most realize.
Links for anyone interested:
https://www.theimmersiveweb.com/
Our Discord:
Given that you mentioned Unreal Engine, why the web and not native?
I mean, this sounds like an awful lot of work to port something to the web, when it already runs in every platform.
How will it reduce walled gardens?
Another question : how, as a player, do you run a game like this offline, or run multiplayer when the game company servers have shut down ?
Sqlite was successfully ported to wasm, maybe something can grow out of that?
SQLite in the browser and at the edge is going to explode in popularity. A slightly unknown feature of SQLite is “sessions” which would allow you to build an eventually consistent system on top of SQLite.
https://www.sqlite.org/sessionintro.html
I can very much see SAAS type apps wheee each costumer/workplace has a SQLite db effectively deployed to the edge.
Something like cockroachdb's serverless might fit too: https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-...
That storm already happened. It was called Unity. And since then others have joined, like Unreal.
WASM + WebGPU doesn't bring anything to the table here other than being a decade late, slower, and with fewer features. Why would anything outside of a web app touch any of it? Why would steam bother? You still have to build so, so much platform-specific stuff to make it work (input, audio, windowing, etc...), why would you do all that and then just pay a massive performance overhead to avoid compiling a whopping ~5 times?
WebGPU could potentially see a use as a middleware for things that want to use the GPU but aren't concerned all that much about performance or overhead, things like image filter effects. But there's also no shortage of existing solutions for them, either, like bgfx (as well as domain-specific offerings like halide of course)
Most devs would obviously still use unreal engine etc, but these engines will be able to give you improved performance of your games by utilizing WASM
Also, not sure where the comparison to a hypervisor is coming into play. As @kllrnohj mentioned hypervisors are relying on actual hardware.
That is why we have signed binary execution to start with, WASM doesn't support any of this.
And since WASM uses linear memory and lacks things like ASLR, the code in the sandbox cannot achieve the same level of protection it could if it was in a hypervisor.
In fact I'm quite certain that whenever portability or security ran up against performance in WASM's design, that performance always lost. Those other two goals were definitely a higher priority for WASM's designers.
Stable, portable byte codes are always inherently lossy. Information that could be (and often is) useful to optimizers is lost in that conversion. Then the conversion from byte code to running code also is on the hot path - it's on the hot path of starting execution. This is the same problem existing byte code solutions face, like CLR & JVM. WASM didn't manage to magic a solution where nobody else had. It's the same thing that's been done to death, just with "web" slapped on the front of it & bundled in a browser. That part of "being in a browser" makes it interesting for web devs, sure, but in the broader context of "all of computing" it's... just not? It's what we already have had (and been using!) for decades.
However, I think it would be possible to make systems in which similar instances, because they are written in a type-safe, memory-safe language in the first place, could bypass WASM and both start up fast and run fast optimised code.
I have done some research on portable bytecodes, and have some novel ideas for getting more performance, but I agree that the inherent problem remains. One thing that help make optimised C/C++ fast is that optimisers assume that undefined behaviour doesn't get triggered. But in a system for portable code, you can't just assume - you'd have to prove that it can not exist to be able to do the same optimisations, and that is far from straightforward. And when it triggers, it has to work the same say, or it won't be portable (bug-compatible) between hardware.
except it is, WASM is designed to be AOT compiled to native code.
Sure there is a bit of difference, WASM needs additional bounds checks and WASM also doesn't have all the info a more high level compiler has.
Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
Interesting, I didn't know that. How does WASM handle different architectures? Do you build different binaries for x86/arm? Or does it do it the Apple way with the giant bundle that contains all binaries?
> Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
Agreed, that was badly worded. Like you said, one could compare a module written in Unity and compiled to whatever Unity compiles to/is implemented in these days with a module in WASM.
Edit: Or does the AOT mean that the format that is shipped is some non-native format but the client compiles everything before the first run?
The same way JavaScript or C#/Java do. It's a bytecode format (typically the first stage in today's JavaScript engines is to turn into a bytecode), which the different engines then JIT for the OS and architecture they are running on.
For more details on a couple different engine implementations, you may find the below of interest.
- https://v8.dev/docs/wasm-compilation-pipeline
- https://hacks.mozilla.org/2020/10/a-new-backend-for-cranelif...
AOT is a counter part to JIT:
- AOT ahead of time (but still on the system, e.g. just before running)
- JIT just in time (while interpreting code you notice a hot section and turn it into native code)
So what most WASM runtime do is parse the WASM byte code, running certain checks for wellformedness and emit assembly (with necessary bounds checks, etc. to not escape the WASM sandbox).
This doesn't mean you can't interpret it, or interpret + JIT it, it's just that AOT seemed like a better choice then JIT or pure interpretation for WASM, as just interpreting it isn't fast enough compared to JavaScript JIT/or asm.js, to make it worth adding it to the web.
Don’t get me wrong, I’m card carrying Unityman and just backed off of XR development recently in favor of more stable webdev work… but WebGL as a solution to high-performance browser gaming was an absolute shitshow from start to finish and I’m not even sure WebGPU lands in time for anything useful to be done with it to deprecate WebGL “support”. I assume that the lightweight 3D solutions based on threejs, etc. are going to drag the rest of the game engine industry kicking and screaming into whatever best solution arises and this wasm-as-k8s sounds like a neat component of that.
Games on the web face far greater issues than WASM or WebGPU can solve (like a complete lack of an asset delivery pipeline), unless you're only after casual flash-style gaming anyway. But mobile largely replaced that market.
To give you a scope of the problem of game assets, "small" indie games like Stardew Valley or Terraria are close to 500MB. How on earth are you going to deploy that on the web?
And if you are assuming a reliable, super-fast internet connection to stream game assets over (along with paying for the CDN to host it), well cloud gaming already does this better and already exists in a meaningful way. Why struggle to fight with the incredibly pathetic limits of a web browser when you can just stream a video?
With lazy loading? Or just an installation progress bar. What's the problem? The user has to click on the permissions dialog, allowing extended space usage, and that's it.
>reliable, super-fast internet connection
It wouldn't need a connection more reliable than what Steam requires for proper functioning.
>along with paying for the CDN to host it
I assure you the costs for a minimally successful game are minuscule when compared to the 30% cut Steam takes.
What you lose is the exposure that a release on a store like Steam gives you. That's not an insignificant problem, and is much more problematic than all the technical stuff you've mentioned.
>Why struggle to fight with the incredibly pathetic limits of a web browser when you can just stream a video?
Answered in a different comment.
And now you're back to 2006 era performance on a good day. 72 Mbit/s would be considered a pretty good internet connection. It's also the speed of a PS3's blu-ray drive.
People have been complaining about the 80-100MB/s on the outgoing generation of consoles for a long time now. Regressing by ~10x isn't a compelling argument.
> Or just an installation progress bar. What's the problem?
Without background downloads or updates? Every time someone wants to play your game, they're forced to stare at a progress bar that can easily take upwards of an hour depending on the game ("smaller" 3d games like subnautica push 10GB)? And you somehow don't see the problem?
> I assure you the costs for a minimally successful game are minuscule when compared to the 30% cut Steam takes.
And I assure you that you don't have to deploy on steam, either. You can both be a native game and get all the benefits of it and not pay anyone an app store fee! You don't have to suffer the web's treadmill of being a decade+ behind to have that.
If it's loading faster than user "consumes" assets, it doesn't matter how fast it is. It's not different for native games that allow you to play earlier than the whole thing finishes downloading.
>And you somehow don't see the problem?
Don't stupidly update the entire thing every time? Send deltas? Don't update as often? As for not having background updates it's a minor issue anyway (I for example don't start Steam unless I'm going to play), and there are Progressive Web Apps and Service workers to solve this issue.
>You don't have to suffer the web's treadmill of being a decade+ behind to have that.
Whoever needs the latest features can of course use a native platform. For developers who don't need the latest features or especially heavy graphics, WASM+WebGPU will be a viable option. That's all.
>You can both be a native game and get all the benefits of it and not pay anyone an app store fee!
And the user has to risk trusting me executing native code, which would definitely lower conversion rate.
AAA titles are already constrained by hard drive bandwidth, which is measured in Gbps on newer systems. They can’t keep all assets in memory. You’re going to have to have a top tier internet connection to get the same performance.
On top of that a browser thread can’t rely on having much more than half a gig of RAM assigned to it.
AAA titles are famously heavy in both GPU and CPU loads, and nobody is proposing to run them in a virtual machine, especially in the 32 bit one. ( memory64 is at the proposal stage)
2. The reason we don't see them anymore is because it's far easier to monetize them on mobile.
An interesting article on the topic (not written by me): https://www.fortressofdoors.com/tag/instant-games/
Someone watching YouTube videos is sucking down hundreds of megabytes if not gigabytes per hour: the higher-resolution the video the more bandwidth required. Most video game assets require less bandwidth (megabytes per minute of consumption time), and can be cached locally.
When designing games for the web, creators will have clear incentive to apply more aggressive compression to everything they send over the wire and figure out how to make do with smaller assets, to cut bandwidth. Games designed to be downloaded have a relaxed size budget and can afford plenty of inessential bloat.
This is completely incorrect. Games regularly saturate and are limited by the 80-100MB/s that can be streamed from a PS4 or Xbone hard drive. This is in fact the biggest differentiating feature of next gen consoles - the switch to NVME and even streaming directly from disk to the GPU, bypassing the CPU bottleneck.
Meanwhile YouTube video, and indeed most streaming video, is well under 10MB/s. Netflix is even content to only recommend 25mbit/s for 4k HDR content.
> Games designed to be downloaded have a relaxed size budget and can afford plenty of inessential bloat.
This is such an arrogant and asinine statement. Games already exclusively ship highly compressed assets. They aren't just pissing away storage space for the lulz, and if they only tried a little harder could somehow cut sizes to 1/1000th of what they are today. Especially not to satisfy the needs of a platform that provides nothing but problems and headaches.
You can't simultaneously claim that WASM and WebGPU will enable a new era of high quality web based games while just entirely ignoring all the actual problems with shipping games on the web. Which WASM and WebGPU literally solve none of the issues. WebGL2 is already competitive on feature set and capabilities with mobile, and yet casual web games are still largely dead - a regression from the flash era, even.
> This is completely incorrect. [...] YouTube video, and indeed most streaming video, is well under 10MB/s.
10 MB/s is the same as 36 GB/hour. So we are in agreement.
But what game uses more than 36 GB of assets for 1 hour of play? I can’t imagine that is at all common. What kind of assets are they shipping that use that much data?
Think of it as if video keyframes were 1GB. Video streaming wouldn't exist in such a world as nobody is going to watch a loading spinner for 20 minutes. No, it'd all be a world of pre-fetched, downloaded content. Which unsurprisingly is exactly how game stores & consoles work.
Here's some coverage of the storage architecture of new consoles and why it's such a big upgrade: https://www.anandtech.com/show/15848/storage-matters-xbox-ps...
Trying to shove lazy asset loading over the internet into that picture just doesn't work.
Yes, and my estimate was “hundreds of megabytes if not gigabytes per hour”. So apparently Netflix also agrees with me.
> Games need to load that much data in under a minute.
This is based on design decisions from the programmers, not some kind of iron law of nature. Obviously you can’t just drop a game designed for one set of constraints into an entirely different context without change and expect it to work precisely the same way.
No, it's based on that's what textures and model quality expectations are. Reducing that size is directly reducing image quality.
You can make a web based game that looks straight out of 2002, sure. But you can't make one that looks contemporary, and WASM+WebGPU aren't changing that.
And of course no game developer is going to bend over backwards and make their game look like shit so it can run in a web browser for no reason other than to satisfy the ridiculous beliefs of web evangelists.
A friend of mine just got 350 Mbps optical fiber to his house. I was wondering what would come along to eat up that kind of bandwidth, you just answered the question. Someone playing a game on the web could also be seeding the thing on bit-torrent at the same time, thus cutting down the hosting fees for the developer.
3D API for 2010 hardware or last generation raytracing hardware, what do you prefer?
Unity cannot do anything against castrated 3D APIs.
No wonder streaming is where everyone is going instead.
That is absolutely not going to continue being the case.
> No wonder streaming is where everyone is going instead.
"Pixel streaming" is great if you don't have latency requirements or your client has a poor GPU, but otherwise native 3D is superior.
Heck, 10 years of Web 3D and still there are no proper debugging tools that match native ones.
The ecosystem will explode, and the tooling will come with it.
What all of them have, is being able to take advantage of 2022 hardware in 2022, with 2022 3D APIs.
As far as I know WebGPU doesn't lack any significant features beside raytracing (They are prioritizing the MVP, and raytracing could come later). Some of the newest features like mesh shaders are not yet supported by the native engines either, because there isn't a sufficient hardware base. Intel for example will support mesh shaders only in the yet to be released Alechemist GPU.
10 years later there still isn't something at the same level of Infinity Blade.
It definitely won't kill Unity or Unreal, but I have hopes that it will make developing without a ready-made engine a bit more attractive at least!
Want Vulkan/DX12/Metal without boilerplate?
Just use Ogre or Godot, among endless other options.
Even Qt is better than what WebGPU is capable of.
Castrated how? A single digit performance loss compared to the most extremely complex graphics APIs which aren't properly cross-platform?
>Want Vulkan/DX12/Metal without boilerplate?
>Just use Ogre or Godot, among endless other options.
"I want a graphics API!"
- "Use this game engine or this old and outdated graphics library instead"
>Even Qt is better than what WebGPU is capable of.
Ah, is it? Do you have any example of implementing forward+ rendering in pure Qt? No? What about GPU compute? Not that either?
By its nature cannot be more than that what browser do.
In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
I guess you were too busy keeping up with WGSL changes to notice that.
What security contraints are you thinking of which are making it castrated? In what meaninful ways is it castrated?
> In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
So with Qt, can I write a complete renderer with advanced techniques, and have it run on all 3 platforms without changing a single file? If not, how is it relevant to even mention?
Here is a little secret, thanks to extension spaghetti and driver bugs, there is seldom "without changing a single file" unless it is some toy app, instead of being used across all possible consumer hardware.
Plus you are focusing too much on Qt while being defensive for WebGPU on native deployments, there are plenty of other middleware I can use as example.
What are you talking about? Are you saying that https://doc.qt.io/qt-6/qsgmaterialshader.html is less "castrated" than WGSL ? Doesn't look like it. I don't even see the spec, it only says "Vulkan-style GLSL"
>Here is a little secret
Google and Apple definitely have more resources to spend standardizing WGSL (WebGPU has a Conformance Test Suite) than whoever owns QT this time of the year.
Because I still haven't heard a single argument against it from you that isn't extremely vague and handwavey.
For example, you skipping over my questions regarding more details on what you think makes WebGPU bad/castrated, or what is making Qt the better choice over WevGPU? (ignoring the fact that Qt doesn't seem to have a common shader language)
I'm open to hear the reasons, but it seems like your goal is to be contrarian.
> - "Use this game engine or this old and outdated graphics library instead"
That is the actual answer for when people ask that question, most of the time. Almost nobody is asking for a raw GPU API, which is what Vulkan, DX12, and WebGPU are. Rather they want a graphics API. Something that provides utilities and helpers. Something that can actually load textures, models, and animations. Or has a particle effect system.
But if all you want is a GPU API, as I mentioned far higher up in the thread there's no shortage of those today either (like bgfx, or even Angle). 'native' WebGPU isn't addressing some unserved market here.
Although if you actually do want a GPU API, there's also a good chance you actively don't want to use a middleware like WebGPU since it limits what you can do and gets in the way...
I'm mostly thinking of indie game devs who decide to write their games from scratch (which still happens, though it's becoming rare), or up-and-coming game engines such as Bevy. They might not have a team who can spend the time optimizing Vulkan (while also making sure MoltenVK runs it fine, if they want to target MacOS), and might prefer something more modern than OpenGL.
>WebGPU since it limits what you can do and gets in the way
Does it do that more than OpenGL ever did though?
And since you need to be Epic or a multi-million funded team with big scale to do an AAA game, but everybody could do a casual (and even more a hyper casual game), I'd say the latter is smarter than sneering on simpler games...
You might not care for those, but billions do. Heck, Wordle could make 10 times the money an average FAANG made in their whole career if it chose so...
https://careers.unity.com/position/software-developer-unity-...
Our startup is working on support for Unreal to support WebGPU from 4.24 onwards, and we've already upgraded support so developers can use WebGL 2.0 instead of WebGL 1.0 like was available previously before Epic made it a community supported platform extension.
> - Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime.
> - Embedded electronics, simplifying the development and deployment of IoT devices.
We will finally be able to write code once and run it everywhere! I bet at least 3 billion devices will run WASM. It's a breakthrough, how come nobody came up with such great idea yet?
Cross-platform Virtual Machines have been around for a very long time, enabling exactly the kind of thing you're talking about. So in-fact, lots of people thought about this, and built various versions of this. The browser doesn't bring anything new to the table here: it's yet another high-level abstraction layer which inevitably will incur performance penalties in a setting where performance means everything. People want to play complex, immersive games at 60 FPS with amazing graphics and textures, sounds, single/multiplayer settings, and more.
The browser was never built for modern triple-A gaming in mind, which means the APIs available for game creators will inevitably be less flexible and lag behind the more platform-native APIs we've had for 30+ years. This isn't a precedent by the way: recently developed APIs such as WebAudio & WebWorkers are just awful and don't come anywhere close to what a desktop application can do on a modern OS, and those are often considered "cutting edge". Synchronization APIs and locking primitives are only now being introduced to browsers - https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A... - something games could easily make use of outside of the browser for the past 40+ years.
Lightweight gaming can easily take place within the browser, and perhaps this new technology can make that easier to build and use. But to build a proper heavy-weight game - you'll need much more than a browser can offer.
Completely agree that web despite being perfect for light weight and casual gaming, is not (yet) the platform for AAA games.
WASM is like Java bytecode without access to the Java standard library (like, no `java.lang.String` or even `java.lang.Object`... just the primitives).
But it has a mechanism to call "host" or "imported" functions and to use linear memory (an array of bytes which can be shared with other modules and the host), which is how it actually does anything useful.
I can imagine a version of Java that works like this as well, actually, I wonder if there's ever been anything like that?
"Once".
That GC proposal isn't anywhere close to landing. It's making progress, but it's the "Zeno's paradox" kind of progress where the feature seems further away the more they work on it. I wouldn't be surprised at all if it still wasn't supported in browsers in 10 years.
"USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly"
https://www.youtube.com/watch?v=glL__xjviro
Then there are the issues that since WebAssembly doesn't prevent memory corruption, while RCE attacks or sandboxing breaks are not possible, by producing memory corruption, it is possible to eventually trigger alternative code paths that wouldn't be possible in normal circumstances.
A contrived use case would be to validate a user with higher credentials that they are supposed to have, in a WASM based security module.
Then since the external calls from the module are configured from the runtime, one can do man on the middle attacks on the functions being called from the module, thus access data that it wasn't supposed to be made available in normal cases.
And I bet that when the hacker community starts having fun with WebAssembly, as much as they have had with other bytecode formats, more issues will be found.
It's less of a problem in 2021 than it was in 1995.
Ironically, those boycotts are now meaningless given Chrome market share, including Electron.
For desktop use, it just never had a good GUI API.
Cloudflare already has a free caching layer, a freemium eventually-consistent KV store that optimises for frequently-read items, and a strongly-consistent datastore. Besides, they partner with other database vendors too: https://blog.cloudflare.com/partnership-announcement-db/
I think you are referring to the upcoming R2 object store? I’m not aware of what I would think of as a “strongly-consistent datastore” which would be closer to a traditional database with querying. It’s that that I think is missing.
Quite right they have partnered with other db providers, however I think there is a need for something native to their platform that ensures good proximity to Workers to ensure low latency.
Then there's the huge advantage of encouraging more competition in the CPU market. Something like RISC-V would have a much better chance if you didn't have to recompile everything for it.
I'm surprised native binary is still the standard. Back in the 1990s when I saw Java and then .NET I thought it would be dead by now outside of specialized high performance libraries for things like codecs and cryptography.
https://twitter.com/RReverser/status/1471623675623481356
Yes, wasm threading support on the web uses workers + SAB. There are some limitations (the usual issues with blocking on the main thread on the web), but it works well in production for many things.
Cloudflare Durable Objects is exactly this.
You still need something like K8s, even if you're not using docker underneath . Indeed you can already use other runtimes under K8s, so what he is proposing is nothing new anyway.
Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it.
Before containers became a thing, everyone was happily deploying their Java applications on Java application containers (Tomcat, Weblogic, those things, remember?)... so I wouldn't say it has nothing to do with Kubernetes... just wait a bit and you might as well see the new generation of Weblogic written on WASM.
> I compare WebAssembly to K8s, but really it's more like processes and private namespaces. 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.
> One thing does seem clear to me though: WebAssembly will be at the bottom of the new thing,
Edit: formatting
[0]https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
I think that's kind of essential to understanding the role Kubernetes fulfills: it's an automation platform.
It's like saying QEMU is the new Systemd; it doesn't even make sense, it's a category error.
In that sense, wasmtime is an alternative to runc for wasm/wasi.
In no way is any of this a replacement for a high level tool like docker.
Until XyZ is the new WebAssembly and @!# is the new XyZ!
As long as my Django backend works and browsers support my HTML/CSS/JS frontend, I am fine.
I have the same LAMP (Linux, Apache, MariaDB, Python) SAAS project running for decades now, paying all my bills, letting me live a free life.
As long as nobody touches that, you can do all you want. Invent new fancy stacks every other year, make courses for it, migrations to it, a religion of it - I don't mind.
SPAs are good for some things, but those things are much fewer than what we use them for.
I'll stick to Rails though thanks :)
Never look back at working tech folks. That's today's lesson. If it works, don't just fix it -- remake it, rebrand it, and overcomplicate it!
Jython is a thing.
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 extensions 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.
That is the thing with WebAssembly marketing, not being aware of bytecode formats history.
Java, by the way, also isn't stopping you from storing all your data in one big ByteBuffer, which is how WASM handles memory.
Jython has been a casualty of the 2 => 3 transition.
Or containers.
Containers are fine for a server after installing the runtime, which is already one too many steps. There isn't a self-contained app format that can run without installing something else before starting it.
First they do containers to replicate application servers, and now WASM to replicate bytecode server side.
In fact I consider Kubernetes much worse experience, regardless of how much hate Websphere and Co might get.
My biggest concern with K8s is how the entire ecosystem is a costly affair. Can I run a service with multiple nodes for 10-50$ per month?
This is why I'd love WASM to win. Right now your browser can run 100s of tabs, with inter-tab communications and all the security sophistications on a single machine. For me, this symbolises a future where WASM can bring cheaper computing to the cloud as well. I don't want to pay a fortune as AWS/Azure bills just because k8s is a costly ecosystem.
You need to connect your cluster to public Internet? No problem that's $x for each load balancer (whether its needed or not).
Ohh you are feeling the whole thing feels like a blackbox and difficult to debug or observe? No problem that is $x for data dog.
Gcp is the worst when it comes to setting up k8s with preemptive nodes. Thought you could get away with preemptive nodes? Not so fast, we restart all the nodes together at end of 24 hours period so that your multi node cluster will have zero availability for 5 minutes everyday. Or jump through hoops to killing your own nodes periodically to keep them all restarting at the same time.
If you like you can install a free ingress such as NginX and route traffic to it.
If you like you can just have logs on your physical nodes and go look one by one, just as you would have to before things like k8s came along. Datadog is a value add. It's not essential.
GCP preemptible VMs are nothing to do with k8s - they are literally designed to be short-term (up to 24 hours) VMs to do things with. Yes, GKE can use them, but not as persistent resources. That's not what they're for.
Here's what they're for:
> Preemptible VMs are Compute Engine VM instances that last a maximum of 24 hours, and provide no availability guarantees.
I.e. don't try and "get away with" them. There are plenty of options for cheap K8s.
I think k8s actually saves you money, because it allows you to use your resources better.
I've worked with it for a bunch of years now and run a cluster at home, but I do hate that it scales down so poorly. Is so much work to run a bare minimum, if not for SME-purposes but for local development. It's just starting to get acceptable.
doubt it as there was JVM back then.
>This is why I'd love WASM to win. Right now your browser can run 100s of tabs, with inter-tab communications and all the security sophistications on a single machine.
Now just add K8s on top to orchestrate it :) Somebody will just develop new WASM based container ...
>[...] WASM is Java for the haters, so it sells much better at the bytecode shop.
Which means WASM was advertised as a new bytecode VM to replace Java.
What I'm saying is that, for these supposed Java haters, why did they choose to completely reinvent the bytecode VM when they could have just chosen Kotlin and not have to reinvent the wheel? It would fix most if not all of their concerns about Java.
I have one server with 1 GB RAM. Can I start with that? And expand on more servers later if need arises.
For small scale development, plain docker/podman is better in my opinion.
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.
As a sidenote: most of the software that i run (Java, .NET, Ruby, Python, Node, Go, PHP) all is memory constrained most of the times, so when looking for server specs, i usually prioritized the memory the highest, CPU, storage and network speed all usually being a secondary concern. Sadly, in the current day and age, i'm not sure how far you could actually get with 1 GB or why even use container orchestration at that point. The smallest VPSes that i have come with 2 GB of RAM and even those are for smaller pages/proxies and such, whereas the majority have at least 4 GB (since GitLab and Nexus won't launch and work with much less) and my homelab servers have 16 GB, whereas my workstation has 24 GB at this point, because that's all that i can afford.
Wirth's law be damned, i doubt that even OSes will work well with that much in the future, especially because of desktop software being infected with Electron and server software having JVM eat as much memory as you'll give it (though that also happens with MySQL or MariaDB). I don't care about "Unused RAM is wasted RAM" as much as others do, i just want to run more stuff on my servers and to have software that doesn't NEED the memory not take it.
I used k3sup to setup my cluster, but that was just for convenience.
I have been running it on those for a while, but also on other SBCs. You can grow the single master by attaching one or more workers to it. The "pain" is mainly that you can't expand the single-master to a multi-master setup, so once you want to go beyond a single master, you have to re-install it all. On the other hand, with k8s you have all deployments, etc. in yaml files and you simply redeploy these on the new cluster.
My remaining pain-point is persistent storage - it's simple to run complex setups with stateless containers or that can retrieve there data at initialization (i.e. a secondary name server that populates itself from the master at startup), but for classic databases I currently still have a manual step to import the DB dump once the service got (re)started/migrated.
Sources: - https://k3s.io/ - https://www.jeffgeerling.com/blog/2020/installing-k3s-kubern...
K8s operates just fine on 1GB nodes. It's very low overhead.
You can operate it on a single node cluster, but that's generally not recommended, not for performance reasons, but for redundancy.
The reason larger nodes are recommended is that k8s is for fleets of applications. If you are only talking about a single service, then a k8s cluster is overkill.
K8s is the cheapest way to run a fleet of microservices.
There is mini-Kubernetes implementation, but I don't know if they're any good for production.
There seems to be a limit to how small you can go with Kubernetes in my mind, and most people never need to cross the line where they're large enough that Kubernetes makes sense. It's honestly a niche product, but right now it's being viewed as a catch all solution.
Just like "if we had internet in the 19th centry", it implies so much more.
If your service can run on few nodes, do you really need a scheduler like K8s? Why not go serverless like Fargate or CloudRun?
Anyway, to make WASM useful as a server platform it will end up re-implementing the entire Linux kernel API.
What I want to know is, is there anything out there like kubernetes but stripped down to just the control loop engine part? Like a glorified IFTTT but without all the overhead and baked-in assumptions of k8s. Some kind of daemon/library where I can write an arbitrary controller which reads a spec, queries some state, and has actions to push the system toward the desired state.
The actual I/O is just writing an API and could basically just be a CRUD. What I'm looking for is the state management engine; that is tricky.
Not super familiar with Hashicorp's other product Nomad but I'd think it have a similar approach, but more of a continuous lifecycle check?
For the workload side of things you have hashicorp nomad. Which is basically a stripped down version of k8s.
If something takes to long to pass a health check you often do not end up in State A or State B. There is a lot of surface area for undefined behavior.
Thank you for this comment. I was scratching my head wondering what developments I had missed on the wasm side of things that would replace k8s.
So essentially wasm could replace or augment the CRI in k8s eventually. That sounds great if it can be properly integrated with the rest of the platform like Ingresses, PSPs, etc.
I wrote my own as a rust library, and I'm in the progress of further breaking it apart. Might get a prototype finished this weekend and if so, I'll share it here.
You could replace the containers that are being scheduled by Kubernetes with WebAssembly. Others already linked to Krustlet which is effectively this.
It's like we are doomed to reinvent certain kinds of technology (with circumstantial advantages due to historical context). Runtimes, process orchestration, databases, the works, everything old is "new" again.
Hang around long enough and you eventually see all the old culprits re-branded and sold as the solution to the world's problems.
At some point, one might get wise and look at the points of stability in the industry and try to understand why. Nobody is going to sell you on stable, though. There's less money to be had if you are satisfied already.
What a nonsense title.
K8s is about far more than simply running containers. WebAssembly only, at best, solves the problem of running a distributable.
This article focuses on one of the smallest aspects of k8s.
* 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?
A) a way to package any bit of functionality in a standardized way
B) run it in any environment.
Docker delivers both, although docker images are large (as they include their own OS) and (contrary to what the article claims) somewhat less efficient than running on bare metal.
Executable files provide A, but are specific to an operating system. They are however much smaller and make better use of the hosts resources as they don't require virtualization.
WASM delivers A for a subset of languages and B in so far as it runs in a browser and specific standalone runtimes.
These are certainly some attractive qualities, but it leaves me wondering: does it make sense to introduce yet another standard into the mix or wouldn't it be better to write a "Kubernetes for executables" rather than having the additional abstraction layer of WASM?
There are workarounds for invoking Docker containers from some other operating systems (e.g. Docker Desktop for macOS and Windows), but those work by installing Linux into a virtual machine/hypervisor, and using that to run the containers. If that's what counts as cross-platform these days, then the term is meaningless (e.g. there are Gameboy emulators for some OSes, so Gameboy ROMs "run in any environment").
Considering that Docker containers themselves often bundle an entire Linux OS, that results in multiple layers of virtualised Linux operating systems. At which point, why not remove a layer and just ship a VM image?
That is not required.
If you think I'm exaggerating, try to configure a GPU passwover to a virtual machine. It is doable, in your server in your garage, after you spend a considerable amount of hours of your life. In your cloud deployment? Only if you use Google or AWS, and even then, only for a price.
Please, call the Spanish Inquisition, this guy needs to be prosecuted before he gathers a coven and gets away with this perversion.
Of course AWS and GCP charge extra for units with GPUs in them, but I can't seriously expect you think they should stick a GPU in every VM instance for free?
I feel like this is an oversimplification.
The company I work for has tens of thousands of concurrent users, plus dozens (hundreds?) of business partners all of whom are integrating with our platform.
We are not serving static HTML pages like StackOverflow, we have dynamic content and our customers want up-to-date analytics.
So.. how am I supposed to "program and run programs" in this environment?
You act like we invent complexity for no reason, but we are dealing with scale and "I want a simple life where I program and run programs" is like saying: "I want an easier job." Cool. They are out there. They probably don't pay as well.
Meanwhile I'm going to try and fix the mess someone made 8 years ago in the monolith so the business paying my bills can keep making money. it ain't pretty, but its a living.
1. Yes, we do invent complexity for no reason
2. The absolute vast majority of us don't deal with "scale" and most of the things we do can be done with a single beefy server (even for "tens of thousands of concurrent users")
3. Sayin that all SO does is serving static html pages is hugely disingenuous at best
Most simply fail to understand exactly what modern servers are capable of. We continue to read article after article about "scaling out", but you're right, the vast majority will never have the need to scale beyond just a few servers.
I bet most people are running sites smaller than Stack Overflow (Alexa rank #65 [did you know Alexa is getting permanently shut down in a few months?!]).
> We are not serving static HTML pages like StackOverflow, we have dynamic content and our customers want up-to-date analytics.
Yeah that can all still be done with a simple monolithic CRUD app on just a few servers
The fact that wasm is sandboxed allows some genuinely new things. Imagine a JSON file starting with a line that gives a base64-encoded WASM parser for JSON. (Or a hash on a public database if you're worried.) Switch to YAML or TOML by changing that line up top, or add comments to your JSON, or get fed up and ship SQLite databases instead. Oh wait I have security concerns, I need to encrypt this file at rest, better change the code that consumes it—why? The registry has a NaCl container, just prefix the encrypted version with the wasm hash to prompt for a password and decrypt it.
It’s a technique that used to be popular and then died out as networks proliferated—you could no longer be sure that your machine code did the right parse on someone else's architecture.
Your container crashes and we coredump to an S3 bucket. You know what’s better than downloading gigabytes of coredump? If S3 can just let you spin up a container or run a WASM program on the storage node itself. You send the programs to the data so you don't need to pull the data to yourself.
This post describes something like Erlang actors, but if each can be a pure function encoded in WASM... That is also a neat dream. But the next step is the MonadArrow instance, programs sending programs to each other. Then we’re “thinking with portals.”
Not just a dream. https://github.com/fluencelabs/fluence
This will be the case with WASM extensions. You won't be sure what's available in someone else's WASM environment.
The only reason it's not the case with WASM on the web today is because it's so simple, and any differences are dealt with in the JavaScript layer.
> Your container crashes and we coredump to an S3 bucket. You know what’s better than downloading gigabytes of coredump? If S3 can just let you spin up a container or run a WASM program on the storage node itself.
S3 literally has this feature, and it doesn't even have to be WASM. It's called "S3 Object Lambda". It's quite new, so you're forgiven for not knowing about it.
Downloading from S3 is quick and free if it's within the same region, so you don't actually need this anyway.
You can always buy bare metal and have your simple life.
At the time it seemed unrealistic; asm.js was only just invented
At least I hope the nuke was COVID.....
[1]: https://www.cl.cam.ac.uk/research/security/capsicum/
[2]: https://wasi.dev
Kubernetes orchestrating wasm runtimes
Kubernetes isn't really about running many containers sharing a physical hardware. You can do that with Docker as well. What Kubernetes offers that Docker does not offer, is self-healing and resilience when managing many containers spread across many underlying nodes. There is no monolithic "Kubernetes" running. Rather, Kubernetes is designed as a set of microservices loosely coupled and maintaining desired states. The resiliency comes from that design.
Because it is architected as microservices, Kubernetes is also extensible. Operators, for example, which manage a single distributed system (such as etcd, or postgres, or mongodb) can only be created because Kubernetes was architected as a set of loosely-coupled microservices.
WebAssembly is the container runtime without the orchestration capabilities. However, Kubernetes is capable of being modified such that it can schedule, orchestrate, and manage WebAssembly containers: https://cloudblogs.microsoft.com/opensource/2020/04/07/annou...
Also WASM doesn't look very mature to me, and chrome and apple can decide to stop supporting it if they want.
I'm also curious how well WASM works on mobile. I wish WASM could replace mobile apps somehow.
Can Apple ever switch back? Since their valuation depends on their income from the app store, they are forced to continue their policy.
However, is this a valid long-term strategy? Right now, most apps are by requirement single-purpose tools. Is Apple prepared for the time when there are user-generated apps? Much of what web3.0 can be is inhibited if Apple puts a tax on every transaction and prevents apps that change their source code.
Since the US mobile phone market is dominated by Apple, does this give China a huge advantage for developing the next generation of software?
[1] https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
In fairness there's been some very exciting development on that front, mainly pushed by Fastly with their own compute @ edge proposal and opensourcing a set of tools like cranelift.
I think their use case of cloud fonction @ edge is absolutely perfect for webassembly on the server, and I'm actually impressed.
I agree the technology needs to mature a bit more. We need broader langage support, and then we'll have a very powerful and exciting tool to add to our tool-belt.
The author is saying that you will be able to replace docker (I think comparing to kubernetes is wrong) with wasm, because it can run code sandboxed.
Another example is a plugin ecosystem using wasm. Your go program would be able to load plugins written in c, lua or any other language that compiles to wasm.
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.”
In short, if the JVM works for you in an enterprise type role, I’d see little reason to switch now to WebAssembly. But it’s future path as a possible mainstream compile target and functions-as-a-service type platform are interesting.
Currently performance gains in the browser vs JS appear minimal- mostly I’m guessing because V8 et al are so damn good at runtime optimization.
The fact that WebAssembly seems to have fallen off of the hype train means that it may have a shot at being the future of serverless.
edit: I’d add that its origins in the browser leave it with a “download and stream code to compiler” that strengthen its serverless scenario visbility.
> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.
But hey, WebAssembly invented the language agnostic backend.
On all platforms web is a second class citizen and the feature set is the common denominator which means it's always lacking something. It doesn't have access to all the hardware, it runs in a VM (which I assume means it is slower) and the dev languages are meh.
I prefer something along the lines of what Fuschia promises. That is, ephemeral software that gets downloaded lazily and runs natively as a first class citizen of the underlying OS
You write your code in any language and compile it to WASM.
You inject capabilities such as file system access, network access, etc.
There is no UI layer, so CSS has nothing to do with WASM.
Although WASM was invented and developed primarily in the browser, it is now being deployed standalone by companies like Fastly that let you customize their CDN with WASM running at the edge of the cloud via point of presence (POP) data centers.
WASM is a very low level building block that you could build something like Docker out of, but it isn't a high level virtualization product.
One of the reasons that containers have been successful is that, in many cases, you can lift and shift an existing application into a containerized environment with no or minimal changes. I don't think that's the case with web assembly at the moment.
I kind of liken it to Serverless, which is great where it fits your application architecture, but hasn't really become ubiquitous the way some predicted it would.
This. I would really like to hear the opinion today of all those 2016-2017 gurus that were telling us "serverless is the only future".
Can you elaborate on where the cost is? Definitely not cloud spend..
Engineering time? Serverless Stack takes almost all the pain away (vs serverless framework)
Could you elaborate? We've got both, but we're not seeing a lot of differential in price.
It could simply be we don't have enough traffic that would drive this correctly.
A bit more detail on the scale / general usecase or features would be handy to know.
In other words, WebAssembly is another step in the saga of systems that try to fill the hole left by the absence of capability based security in the Operating System.
If it gets me a way to get back into the business of developing programs for a desktop, and avoiding worry about details of web servers, tls, caching, and endless browser specific bugs, I'm all for it, especially if I can write a program that uses a PowerBox to get a capability to a local file. At that point, I could just load the file from a disk, or via the web server/browser pipe, and it will work the same.
Eventually, someone will figure out that a capability based OS for the desktop could launch a trillion dollar market for new applications without the need for a vendor specific web store or lock-in, and we'll be off to the races again, like in the 1980s shareware boom.
Linux containers (LXC) are designed for running applications whereas Virtual Machines (VMs) are designed for running Operating Systems. So, they are nothing alike and any hint to "evolution" is just more complexity layered on by people who have nothing better to do than make things seem complicated.
Not every application needs this type of complexity. Sometimes an idea or application can just run on a regular old VM until such time it doesn't and then I put it on AppEngine, where it's technically K8 and Docker, except I don't have to think about it.
The amount of complexity K8 and Docker brings is not worth the time and effort require to learn those things well if doing one's own deployments. I'm thinking back to Docker literally uninstalling itself SEVERAL times on my laptop, leaving itself in a broken state. Sure, I can learn these technologies a little, but I am certain problems will crop up over time that whittle away at the usefulness of choosing to use them over just using older, more well known methods to get shit done.
For applications, I think Docker is the way to go.
I don't really think we'll ever actually get there, but that's the hope. And even if we do, we're stuck with the DOM APIs until the heat death of the universe.
1. https://github.com/suborbital/reactr 2. https://wasmedge.org/
Progress!
I don't see how webassembly would by any different from just running a JAR file or similar in terms of ease and usability. It's just a new method of writing bytecode that can do less. Bytecode interpreters already struggle to make efficient use of things like SIMD and this is just another layer on top of that.
What's the point of using low level languages if you're going to compile them to semi bytecode. You can already set up virtual machines with predetermined state of any kind, see Firecracker for example, there's no need for a WASM overlay.
WASM is a cool technology, don't get me wrong, but in my opinion this is a stupid way to use it.
https://deislabs.io/posts/introducing-hippo/
https://docs.microsoft.com/en-us/azure/aks/use-wasi-node-poo...
https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
Just a sample, plenty of others chasing WASM gold.
The idea was great, but it was premature and not well thought.
Any language similar to Java. Small subset of languages.
It is a big crufty old hat full of legacy papers and old scanned computer history.
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).
The big benefits:
* Much easier deployment. All you need is a small .wasm file, usually hosted in a registry similar to Docker. No need for messing with cumbersome Docker files. No need for tooling that audits Docker images for vulnerabilities. No huge image downloads for each service.
* Language interop. Progress is slow, but interface types [1] will soon provide a standardized way for type-safe abstract interfaces between Webassembly instances. This makes cross-language interop seamless and very efficient.
* Much smaller applications. You can move expensive dependencies like http servers/clients, database clients, etc into the runtime and let the environment provide those. This leads to way fewer dependencies, so you don't need to constantly update your apps and aren't harassed by Dependabot PRs. More importantly: smaller attack surface and less opportunity for compromises.
* Security. Webassembly is sandboxed and has a much smaller attack surface than a whole operating system syscall sandboxing layer (aka Docker et al). Wasm also naturally lends itself to capability based security with handles that are passed around, so you can even scope permissions inside your application code. (hint: reference types)
* Easier local development. It's much easier and quicker to download and start 100 small .wasm based services than it is with (often large) Docker images / Kubernetes setups.
* Quasi-instant startup (after the wasm is compiled, or with an interpreter)
* Less resource usage. It's relatively easy to freeze and persist Wasm instances to disk when they aren't used. Or do things like seamlessly migrate them between nodes. Or snapshot and resume them locally for debugging.
* In-browser usage: you can even just run the same code in your browser anytime you want. ( the runtime I'm working on can provide a mostly complete dev environment just in the browser, which works mostly identically to server deployments, excluding obvious deficiencies like no direct network or storage access)
---
Of course things aren't just rosy. Some downsides/risk factors:
* There are quite a few proposals that are crawling through the standardization process. (GC, more control over the stack, tail calls, interface types, WASI, multi threading, module linking, ...). Several of those would be really important especially for interpreted languages.
* Language support. Rust, C and C++ work. This is not so much the case for other languages. As mentioned above, the spec leaves a lot wanting for running interpreters, and few of the popular languages can be AOT compiled. There is a Spidermonkey WASM build that makes running JS feasible, but it's of course much slower than a regular JIT enabled v8.
* Tooling and ubiquity. WASM is basically the next iteration of serverless. And there are many areas where serverless is frowned upon. I feel like this is mostly a tooling problem though that can be solved by a good ecosystem and a powerful runtime.
---
All in all I do believe WASM has the potential to be a very prominent (and hopefully the preferred) way to deploy a lot of applications, eventually.
[1] https://github.com/WebAssembly/interface-types/blob/main/pro...
I'll post a SHOW HN once it's ready for an initial open source release.
How will the runtime know which dependencies to provide, and how won't it be similar to Docker layers?
The WEB + on demand infrastructure is the distributed replacement of K8S
WEBCode is about eliminating environments and the difference between backend and front end to radically reduce the number of tools necessary and to enable new development workflows like live debugging production trafic with the vanilla Chrome debugger.
Kubernetes is first and foremost an orchestrator.
Docker is an environment. You can run Redis, proxies and all kind of infrastructure in Docker containers. Or your own binaries.
The article is making a valid point in distributing binaries. That's all. Nothing new here. If WASM will conquer the world - we'll see. Potential is there. But WASM for the browser was already overhyped. Hype seems necessary in our times but is clearly not enough.
I find it interesting at least, but I haven't had the time yet to play around with it.
I commented about this a few times here in Hacker News [1] [2]. I believe WebAssembly/Wasmer will become the new Docker (fun fact: the name Wasmer comes from Wasm + Docker) and there is a greater opportunity for it to become the base for the future Kubernetes for the Edge.
Excited for what's to come!
- only big companies need kubernetes (as kesley hightower said, only use it if you building a platform and solving million dollar problem)
while desktop app that runs in browser (games, graphics design, etc) can benefit from wasm, also if you want your service to run users' code, it's better to use wasm so they can choose whatever language they want that able to target wasm
Too much javascript glue code to write
Tomorrow? hell yeah! it is perfect, desktop no longer the lowest common denominator when building crossplatform solutions!
Each peer in a p2p network can host multiple services and expose their API to the network. Each service, then, is a collection of WASM modules that interact with each other in FFI manner.
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
Btw. Betteridge's law of headlines holds.