Enterprise WASM beans ???
And history repeats.
Spin – WebAssembly Framework
51–60 of 76 posts
Re: Spin – WebAssembly Framework
#52This blog post is enjoyable to read. It's a clear and friendly without trying the sell the idea too hard. It respects the reader's capability to understand and evaluate the thing by themselves and makes a good effort build up the required knowledge. Also I like the design. Kudos!
Re: Spin – WebAssembly Framework
#53Earlier quoted context omitted.
(one of the Spin authors here.) This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox. We have not explored exactly how large scale apps will…
> This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox. Yes, "shifting" was a terrible choice of words on my side, sorry about that :)W hat…
Web apps always had a chance to decide who to talk to.
This is trivial when they are clients of some other APIs, so about server side choices:
- domains, if reverse proxies / firewalls give them the IP of the client
- routes, by servicing the good URIs and 404 the bad ones (attacks more than honest mistakes)
- users, with many different authentication systems
- data, with validations.
The former points are traditionally more in the domain of the network infrastructure, the latter ones are for the application. I've seen all the possible combinations in the last 30 years.
Re: Spin – WebAssembly Framework
#54Earlier quoted context omitted.
Hi! (one of the authors of Spin here.) As you can assume, we are just as excited about all the places where we can run WebAssembly! That's a pretty intriguing idea, looking forward to seeing it evolve!
Thanks, and I'm really rooting for Spin's success. The cloud computing costs have reached ridiculous levels recently. I blame the new age DevOps culture trained to hit every nail with Kubernetes ecosystem for this inflation. I believe WebAssembly could be the liberating weapon against these rising infra costs. I see Spin as a small step towards that future of affordable cloud computing. Here's a twitter rant I wrote…
Enterprises were using (wasting) full ec2 instances long before Kubernetes came along. K8s can certainly be used to get more utilization on a small cluster -if that's something you value.
And that's just it, most companies I've seen are content to ship code and deployments that are poorly architected (for performance and efficiency) and poorly performing.
I saw the same thing when I worked in the energy space. Effort is only expended when the ROI is big enough to justify it. And sometimes not even then! It's kind of depressing.
I actually think that the silly high cost of cloud infra can help bring about an appreciation of leaner runtimes (Go, Rust, etc) especially with cheap edge computing (cloud flare workers). That's an uphill battle though.
That said, I can envision a leaner orchestration model ( leaner than k8s) that strongly encourages more efficient computing. I'm excited to see how WASM fits into this, it could be a game changing tool for simplification.
Re: Spin – WebAssembly Framework
#55I am sure this has been answered before, but a quick google search didn't really clear this up for me but... I don't quite understand the usage of WASM on the server side (not denigrating, just looking for an explanation). If you are using rust, can't you just compile it down to a binary and run that on your server? Or is the main advantage the sandboxing? Or is the idea you have a bunch of wasm compatible servers an…
(one of the authors of Spin here.) Your intuition is mostly correct. Before anything, I strongly suggest you read this article on server-side WebAssembly — https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... In short, when compiling to Wasm, you are building a binary that is agnostic of the operating system and CPU architecture it is going to run on, so it can be executed in lots of very different places…
so you're all building a JVM but hipster. Got it.
Re: Spin – WebAssembly Framework
#56Earlier quoted context omitted.
But you can already do this with DLLs or with SOs files. You can keep your network logic for example inside another module (perhaps the host app) and then load the logic that acts on the received data as a dll. Process separation and IPC natively using a library such as Qt is literally a few hundred lines of code.
I can't take a DLL and expect it to work on Linux/Mac. Wasm allows free sharing of portable binaries - with cross-language interop.
But that's sort of moving the goal posts now. Original claim for WASM was that it allows hot reloading. Which is a thing you can do with DLLs just fine.
Re: Spin – WebAssembly Framework
#57Yeah like other snide comments mention - not sure this is that useful or something we really want.
Like, I get the company wanting to sell services to people who might do wasm stuff, the whole quip about cross platform CLI? I don't think devs care, we have multiple tools for that already, thanks, generally I dont think CLIs are selling points to the "end user". If they are, small niche market with crossover with said devs.
The rest of it, been there done that, JVM, JavaBeans. The point of wasm was to allow better browser experiences, not build components in another esoteric runtime. In this regard Wasm is no different than any other scripting language, and this product is another dime a dozen 'enterprise offering', with all the usual pitfall that comes with. "Developers aren't Operators"? Ugh. "We want to chain you to your desk and churn out crappy feature after feature onto our already unmaintainable pile of slop"
Dislike.
Re: Spin – WebAssembly Framework
#58Earlier quoted context omitted.
But you can already do this with DLLs or with SOs files. You can keep your network logic for example inside another module (perhaps the host app) and then load the logic that acts on the received data as a dll. Process separation and IPC natively using a library such as Qt is literally a few hundred lines of code.
I can't take a DLL and expect it to work on Linux/Mac. Wasm allows free sharing of portable binaries - with cross-language interop.
It is also hard to contain the DLL/SO, every system has different mechanisms to ensure it can not access 'everything'. Wasm, as build for the browser, has it in its DNA.
Re: Spin – WebAssembly Framework
#59This looks promising. I'm amazed at the kinds of places WebAssembly has found its way into. I myself am working on putting WebAssembly as a UI reconciliation engine. 1. You write your UI component spec (similar to React) in a language of your choice. 2. This compiles down to a WASM module, that knows how your state interplays with your UI tree. 3. A platform specific embedder can then write a tiny layer of renderer t…
Heh, I've been working on something not that dissimilar from the C++ side in https://github.com/celtera/avendish (at compile time though, but I plan to target WASM so maybe some collaboration's possible) - https://vimeo.com/manage/videos/694659185 ; the definition of the UI widgets don't need to include any library and will be able to compile against Qt and others :)
Re: Spin – WebAssembly Framework
#60Earlier quoted context omitted.
Sandboxing. The new way of doing containers. I'd think of it as plugins everywhere, like L7 proxies [1]. The code for a network filter could be reloaded in the server upon detection to a configuration change. I believe the startup mad dash is on to capture who is going to run the container runtimes, and host the plugin repositories. So my guess is that Fermyon Technologies with Spin could be looking to follow the Ver…
It is more like, container folks rediscovered what we were doing with app servers.
To be fair I don't think this is really the same - if I understand correctly, app servers were always a poor approximation for actual co tainers.
Browser containers may be better, but you share the same problem with app containers that you share physical memory and a kernel space.
Same type of challenges though, yes. Just a brand "new" secure sticker on the front, whatever that's actually worth.