Kubecon Recap: Official Videos & Announcing the Open Beta of the Fermyon Cloud
Tim McCallum
spin
cms
wasm
webassembly
cloud
rust
dotnet
microservices
cloud
kubecon
Last month’s KubeCon/CloudNativeCon and Wasm Day events in Detroit, Michigan, were wildly successful. Our genuine belief that WebAssembly (Wasm) is the next wave of cloud computing drove us to officially introduce the open beta of the Fermyon Cloud on the first day we were there (during the keynote on Wasm Day). For your convenience, this article provides an overview of our conference talks, contains the official videos (embedded) and also offers valuable links to various resources on this topic.
Fermyon Cloud: Webassembly Development Is Easy
We are excited about Wasm’s potential in the cloud space and are thrilled with the uptake of Fermyon Cloud. As our very own Matt Butcher (CEO) and Radu Matei (CTO) showed in the keynote (WebAssembly Development is Easy) we can now go from a blinking cursor to deployed application in two minutes or less.
This breakthrough in rapid Wasm application deployment is significant, especially given that surveys such as the CNCF Wasm microsurvey highlight concerns among potential Wasm developers in areas such as incomplete developer tooling, and also the lack of consistency around developer experience; when using Wasm. Now, you can deploy a Wasm application to Fermyon Cloud with just a GitHub account. We are very hopeful that Fermyon Cloud scratches one of the itches from survey respondents; when asked what steps the industry could take to tackle these challenges, returned with a resounding call for “More mature tools …”.
We would be thrilled if you took Fermyon Cloud for a test drive. There is a quickstart guide for your convenience, and any feedback is more than welcome. If you get stuck with anything or have questions, please chat with us on Discord.
C# and Wasm Interface Types: Hands Accross the C
On the back of releasing and writing about the Spin .NET SDK, a couple of months back, our very own Ivan Towlson gave an intelligent and engaging presentation, commencing by outlining the long journey of .NET and then moving on to some richly detailed explanations (occasionally writing custom C code live during the presentation) impressively covering off, amongst other things:
- how to use C code and the .NET embedding API to bridge between a Wasm interface and .NET user code
- how to export a WIT interface from a .NET library, and
- how a .NET library can access a WIT interface defined by a host or another Wasm module (written in any language)
As a genuinely cross-platform, open-source developer platform with a substantial worldwide developer network, .NET’s ability to now incorporate Wasm into its applications is inspiring, albeit if using some experimental C magic for now. You can find Ivan’s presentation slides and demo code here. You can also try out the Spin SDK for .NET and the very recent Spin Visual Studio Code Extension.
The JVM Meets WASI: Writing Cloud-Friendly Wasm Apps Using Java and Friends
Initially, as an experiment to build a cloud-native application using Wasm and Java, our incredibly talented engineer, Joel Dice, went above and beyond to piece together a good amount of open-source code for some great projects. This new way of thinking could assist in one day contributing to creating the utopian mixed-trust model, providing the best of all worlds and finally realizing that polyglot vision for Wasm.
At an elemental level, we know that Java bytecode can run in a Java Runtime Environment (JRE) and that, similarly, Wasm executables will run in a Wasm runtime (i.e. Wasmtime). In addition, Java’s JRE class library has many APIs that provide access to the outside world, i.e. networking and so forth. Similarly, work is also underway to modularize the Wasm equivalent of these APIs. At this point then, it seems accurate to say that Java and Wasm are now both aiming to successfully live up to the write-once-run-anywhere ethos. So what if we combined the two? Let’s take a look at a couple of recent developments on this topic.
TeaVM-WASI, a friendly fork of TeaVM with Wasi support, will take Java bytecode and transpile it to Wasm in readiness for its execution on a Wasm runtime.
Wit-bindgen will take a set of Wasm interfaces and generate bindings. In addition, Joel’s code that landed only a few weeks ago (in the Bytecode Alliance’s wit-bindgen repository) now provides Java bindings. Joel has some code examples and a demonstration in the video below; impressive development!
This inspiring talk asks about the most logical reason to use Wasm over JVM/JRE. A good answer to this question is, we should use Wasm when running code in untrusted environments. For example, multi-tenant infrastructure requires platform independence and strong isolation; these are two natural benefits of using a Wasm runtime.
Another upside of using Wasm is that the component model has the potential to enable a language-agnostic ecosystem for easy library reuse across language boundaries.
Concerning performance, there are swings and roundabouts. The most interesting is that fast-running microservices don’t require Garbage Collection (GC). So in some cases (depending on design), the ephemeral Wasm VM will vanish, freeing all memory faster than GC can occur (depending on how quickly the execution is). There is still a lot of thought and development potential in this fascinating space.
Wasm Day: Kate Goldenring
Watching our superstar Kate Goldenring articulating the CNCF survey findings, about Wasm being an emerging disruptive technology with a long life ahead, was a pleasure. Wasm is a polyglot with a growing community-driven ecosystem that spans multiple areas (browser, cloud, edge, IoT & more). Below is an embed of Kate’s opening remarks on Wasm Day. The reason we are ending with this video is that it is a great segway for you to bounce off and read the CNCF Wasm microsurvey for your own interest. As the survey’s title says, Wasm is a transformative technology and it is time to get serious about it, enjoy the survey!