11–20 of 76 posts
We went full circle... microservices in web assembly.... one of the worst idea of this decade
Naturally now they have to be packaged and sold as a new revolutionary idea for the newer generations.
I applaud their effort on this! It's great to see push from more companies of WebAssembly on the server-side (disclaimer, I work at Wasmer). I have one nit about the article though. I think I haven't seen the claimed support for the Component Model anywhere in the code (other than naming the Wasm modules components), as its mainly based on the extent of WebAssembly Interface Types (WIT). Could anyone from the team gi…
First, both Spin and the component model are in their early stages, but there are a few things I'd mention here:
- as you correctly pointed out, all "trigger" interfaces are based on WIT (https://github.com/bytecodealliance/wit-bindgen/blob/main/WI...), the new WebAssembly interface format, so a) building a WebAssembly binary that implements a trigger interface can be done pretty easily in languages with bindgen support, and b) extending Spin with a new trigger type can also be done by starting with the WIT interface (really early on this topic, but here's an example — https://spin.fermyon.dev/extending-and-embedding/)
- we want to add support for defining component dependencies, and dynamically linking them at runtime based on the environment.
- all "platform features" we want want to add to Spin will be initially based on host implementations for WebAssembly interfaces (you can see an early example of this in this PR — https://github.com/fermyon/spin/pull/165)
- we are closely following the tooling in the component model (https://github.com/bytecodealliance/wit-bindgen/pull/183) and will add support for natively executing actual components once that is available upstream.
Hope this is helpful!
We went full circle... microservices in web assembly.... one of the worst idea of this decade
Hi! (one of the authors of Spin here) Interesting to hear your thoughts on this, why do you think that? We believe that the things that make WebAssembly attractive in the browser (compact binary, near-native speed, the sandbox isolation model) make it really compelling outside the browser, on the server.
> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.
From https://news.microsoft.com/2001/10/22/massive-industry-and-d...
> It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC.
> Maximum portability is achieved by using an intermediate language using bytecode, called EM. Each language front-end produces EM object files, which are then processed through several generic optimisers before being translated by a back-end into native machine code.
From https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
> The hardware isolation provided by the TIMI allowed IBM to replace the AS/400's 48-bit IMPI architecture with the 64-bit RS64 architecture in 1995. Applications compiled on systems using the IMPI instruction set could run on top of the newer RS64 systems without any code changes, recompilation or emulation, while also allowing those applications to avail of 64-bit addressing
Is the workflow: Build app in rust, compile it down to WASM, and then run it on a server with wasmtime? I think I am missing some step.
what are the benchmarks?
WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benche..., and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/):
- the response times — here are some benchmarks for requests that simulate 1 ms of work — https://fermyon.github.io/spin-benchmarks/criterion/reports/...
- the "cold" startup time — https://fermyon.github.io/spin-benchmarks/criterion/reports/...
Another disclaimer is that we have not focused on optimization work at all, so we expect to make significant improvements over the next few months.
It's not super clear, but it looks like Fermyon was started by people formerly at DeisLabs, which has done quite a bit of wasm work. It looks quite promising, even more so considering the lineage and expertise of the team.
You are correct, a lot of our team worked in the DeisLabs R&D team at Microsoft before joining Fermyon!
Earlier quoted context omitted.
Hi! (one of the authors of Spin here) Interesting to hear your thoughts on this, why do you think that? We believe that the things that make WebAssembly attractive in the browser (compact binary, near-native speed, the sandbox isolation model) make it really compelling outside the browser, on the server.
I think while it is a good idea, more acknolwedgement to previous work should be considered, > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. From https://news.microsoft.com/2001/10/22/massive-industry-and-d... > It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC. > Maximum p…
I think this is an excellent point — while we do try to give acknowledgement to the previous technology that paved the way for what we are doing (there are a few articles that treat microservices, containers, serverless https://fermyon.com/blog/index), I agree that we could do a better job at talking about programming languages and language runtimes.
Thanks for the suggestion!