Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spin – WebAssembly Framework

fermyon.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Spin – WebAssembly Framework

#41

Post by gyre007 »

After working on a microservices framework I've opinions about frameworks but one thing that caught my attention is the shifting of outbound network calls [security responsibility] from firewalls to the [application] runtime.......driven by a config file. It'd be interesting to hear from some security engineers here -- there will likely have to be some tooling written for them, etc., but this is one of the more interesting things about spin/WASM.

I wonder how this will scale to large apps -- assumning thats one of the goals...if the target is just some kinda serverless cruft then maaaybe that can work, but I can already foresee a small config template hell unravelling in front of my eyes.

I might be missing something fundamental here, so take what I said with a pinch of salt.

Re: Spin – WebAssembly Framework

#42

Post by matei_radu »

gyre007 wrote: post #41

After working on a microservices framework I've opinions about frameworks but one thing that caught my attention is the shifting of outbound network calls [security responsibility] from firewalls to the [application] runtime.......driven by a config file. It'd be interesting to hear from some security engineers here -- there will likely have to be some tooling written for them, etc., but this is one of the more inter…

(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 look like with Spin and WebAssembly — our initial target, at least in the beginning, is making sure building and running function-as-a-service(-like) applications is a great experience.

That's a great call-out regarding configuration and templates — we do have previous experience with "config template hell" from working in Kubernetes, Helm, CNAB, and other distributed systems platforms, so hopefully we can try to make things better!

Re: Spin – WebAssembly Framework

#43

Post by emteycz »

ensiferum wrote: post #36
bkolobara wrote: post #30

Earlier quoted context omitted.

I'm the author of a Wasm on the server side runtime[0] that focuses primarily on rust compiled to Wasm, and this question comes up quite often. Why compile to Wasm if you can compile to native code directly? To add to Radu's answer, here are some of my favourite reasons. Having an in-between bytecode layer allows you to build application architectures in rust that would not be possible when compiling directly to mach…

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.

Re: Spin – WebAssembly Framework

#45

Post by mhh__ »

mysterydip wrote: post #44

This may or may not be an issue since they operate on different niches, but spin (and recently spin2) are languages used to program parallax propeller microcontrollers: https://www.parallax.com/propeller/qna/Content/QnaTopics/Qna...

SPIN is also a model checker.

Re: Spin – WebAssembly Framework

#46

Post by debarshri »

lewisjoe wrote: post #29
matei_radu wrote: post #5

Earlier 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…

This is so true. I think this project feels like breathe of fresh air and also forced you to think different on how to go about building serverless stuff.

Someone mentioned about carbon footprint of increase due to containerization and the kubernetes culture during discussion about dagger [1]. Cloud cost, cloud waste and climate impact of current cloud computing setups are some biggest problem of this decade that are often ignored. I think webassembly and frameworks like these are the answer to that problem.

[1] https://news.ycombinator.com/item?id=30857012

Re: Spin – WebAssembly Framework

#47

Post by no_circuit »

pech0rin wrote: post #16

I 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…

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 Vercel with NextJS model where everything will be open source and runnable from the development runtime, but there eventually will be features like Edge Functions [2] in five years that will only be available when you deploy to their hosted service. They'll likely work towards that with web services with Spin [3] and CMS with Bartholomew [4] for starters. Instead of everything linked together in a NodeJS app directly, your code will run from a WASM library in a sandbox.

But my guess about the Vercel model could be slightly wrong after checking out their solid founding team [5] -- the bios emphasize the WASM and Kubernetes worlds. The problem if it is something like the Docker model is that the standard will just be made with the big players like OpenContainer [6] and the enterprise business sold off [7], and/or folded into one of the cloud infra players (with the data centers).

[1] https://github.com/proxy-wasm/spec

[2] https://vercel.com/docs/concepts/functions/edge-functions

[3] https://spin.fermyon.dev/

[4] https://github.com/fermyon/bartholomew

[5] https://www.fermyon.com/about

[6] https://opencontainers.org

[7] https://www.mirantis.com/blog/mirantis-acquires-docker-enter...

Re: Spin – WebAssembly Framework

#48

Post by tormeh »

lewisjoe wrote: post #29
matei_radu wrote: post #5

Earlier 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…

You can run your own workloads really cheaply on a self-hosted Kubernetes cluster on a cheap provider like Hetzner or similar. Cloud being expensive is really just because AWS, Google, and Microsoft are milking the enterprise market. If you're a price sensitive cloud customer go somewhere else.

Re: Spin – WebAssembly Framework

#49

Post by pjmlp »

no_circuit wrote: post #47
pech0rin wrote: post #16

I 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…

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.

Re: Spin – WebAssembly Framework

#50

Post by gyre007 »

matei_radu wrote: post #42
gyre007 wrote: post #41

After working on a microservices framework I've opinions about frameworks but one thing that caught my attention is the shifting of outbound network calls [security responsibility] from firewalls to the [application] runtime.......driven by a config file. It'd be interesting to hear from some security engineers here -- there will likely have to be some tooling written for them, etc., but this is one of the more inter…

(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 I meant was, it gives developers more ways to manage outbound traffic -- which is both great but I wonder how the intersection of Ops and Devs handle this going forward because these things often become contention points at organizations (remember the enterprise proxies, etc.); let's see how this all plays out, but I'm glad devs now have more ways to [express and] manage these aspects of their apps.

Post reply on HN