The Future of WebAssembly in the Cloud: Our Glimpse
Tim McCallum
spin
devopsday
wasm
webassembly
cloud
rust
Minneapolis
microservices
conference
Our very own Michelle Dhanani delivered a face-to-face presentation (Streamed live on Aug 1, 2022) at the devopsday conference event in Minneapolis, Minnesota. During her talk, Michelle shared Finicky Whiskers, a small game (that we designed at Fermyon) which gives a glimpse into what our vision of the future of WebAssembly in the cloud may look like.
More on Finicky Whiskers later in this post …
If you missed Michelle’s presentation you can watch it now by pressing this link (which will jump to the correct spot in the video).
We have also embedded the whole devopsday Minneapolis 2022 Day 1 video below (Please note: the single edited versions should be all be available in a few weeks).
Getting to know Michelle
These days we don’t all get to meet in person at conferences, so here is a quick virtual introduction, to Michelle, for your convenience.
Michelle Dhanani is a founding member of Fermyon. Currently, amongst many other things, Michelle contributes to Spin. Whilst previously at Microsoft, Michelle was a core maintainer of Open Service Mesh and Service Mesh Interface. Michelle has been a core maintainer for projects like Helm and Draft and her vast experience & interest in service mesh technologies has culminated into an ongoing curiosity around what is possible in relation to the future of WebAssembly.
A little bit about WebAssembly (Wasm)
As Michelle mentioned, WebAssembly is a binary instruction format for a stack-based virtual machine. Essentially, WebAssembly is a compilation target. Developers can write their applications in any one of the 30+ languages that can successfully compile to WebAssembly i.e. Rust, Swift, Python etc. From there the .wasm file (bytecode) can be executed anywhere you can execute WebAssembly. Initially, WebAssembly was created to push performance forward in the browser and enables us to run code written in lots of different languages at near native speed on the web.
WebAssembly: cloud & edge
As a result of being developed in the browser, WebAssembly has some really interesting properties around portability, security and speed. The same properties are also really appealing for running applications in the cloud and also across the distributed computing paradigm known as edge computing. Let’s explore these properties a bit more in depth.
The portability of WebAssembly
The portability of WebAssembly helps to take our applications a step further into the future. For example, whilst containers are still an absolute game changer, the container approach that we know and love, requires us to build separate images for each different platform and/or architecture. In contrast, the executable bytecode (the .wasm file we mentioned above) can be compiled once and then run nearly anywhere. This means that you can run that same .wasm file (not only in your browser) but also on many different platforms & architectures ie. ARM, Intel, Windows, Linux, macOS and more. This run anywhere (portable) property of WebAssembly is the reason that we sometimes hear folks refer to WebAssembly as “isomorphic” or “universal” in nature.
Security
WebAssembly has its own linear memory and therefore can not access the memory of other WebAssembly applications (which have been written to run on the same host). A huge advantage, which this property provides, is that a single host can execute many different functions without side effects.
In addition, by design, WebAssembly can not access any of the host’s APIs. For example, by default, the WebAssembly being executed can not read or write to files on the host’s system and so forth. This deliberate deny-all-by-default approach, which is part of WebAssembly’s design, sets WebAssembly apart from all other similar technologies which are available in this space. The safety property is a key differentiator.
Speed
In terms of speed and performance, a WebAssembly module can start up within a matter of microseconds. This makes not using compute resources (when you don’t need them) a reality and a good experience.
Opportunities
Aside from sharing potentially known functions/applications on shared hardware, WebAssembly’s safety property also allows anonymous users to execute their own “user-defined functions” safely on shared hardware (platforms and architectures). From a cloud/edge computing infrastructure point of view this safety property introduces a new potential playing field for “pay-as-you-go” microservices and much more.
Efficiencies
In the aforementioned “user-defined function” arena, compute resources (which essentially execute these microservices) are only provisioned when the user actually needs them. Simply put, the stand-alone stack-based WebAssembly VM is ephemeral; meaning it can spin up, execute code and then spin down at a moment’s notice.
After the execution cycle (when input to the WebAssembly runtime has been received, the business logic has been processed and then the desired result has been returned to the entity making the original request) there is nothing left running (or instantiated) on the host hardware. This default WebAssembly mode of execution is known as stateless execution.
WASI
To be fair, useful applications do require some sort of state, storage and so forth. Therefore, as part of the future of WebAssembly, initiatives such as the WebAssembly System Interface (WASI) are pursuing their ongoing work which is to design principles that facilitate WebAssembly modules securely talking to a few select system resources. For example, on the server side we can potentially support environmental variables and explicitly enable filesystem access and so forth; albeit, deliberate by design with safety and security as the top priority.
As promised above, we will now provide some more information about Finicky Whiskers.
Let’s play a game
With a true passion for what is being developed at Fermyon Michelle’s talk explained how the aforementioned adorable game called Finicky Whiskers works.
Essentially, the game consists of a static frontend, Redis running (as a container service) and then about 1/2 dozen separate microservices. These microservices are deliberately highly cohesive modules which exist to perform a specifically defined task such as “Get the scores for a particular game” or “Initialize session data” and so forth. This style of architecture promotes code reuse; even across different applications (which is a brilliant way to write software).
Each time a button in the game is clicked, a few WebAssembly executable modules are spun up to execute some business logic and then spun back down; over 300 modules were successfully executed during the presentation which is impressive in terms of speed and performance.
If you would like to take a deeper dive into how the Finicky Whiskers game works, we have a 4 part blog series which you can read here.
As the blog series explains, the Finicky Whiskers game is a demonstration of microservices rethought. The game’s operation sends hundreds of requests to the cloud, where a Spin server listens for requests and then (the Spin server) executes each of those WebAssembly components. Let’s talk about Spin …
Spin
Spin is an open source framework (created and maintained by Fermyon) for building and running fast, secure, and composable cloud microservices with WebAssembly. Spin configures the execution environment for your application so you can just concentrate on your business logic. Spin is highly configurable and comes with a variety of pre-built templates i.e. HTTP request handlers and Redis message handlers. Spin is open source, and whilst you can start from scratch, you can use these templates to scaffold an application for you.
Michelle showed how a developer can create a new application, then build and start the application locally, in just two commands.
spin new http-rust hello-world
spin build start-up
The above commands will build the hello-world application’s environment (files and folders) which can perform request and response activity on the host’s file system.
Microservices
The ready-made spin.toml file in the aforementioned application environment allows you to configure your application’s functionality. Specifically, it tells Spin where the WebAssembly components (.wasm files) are on the host and also describes how that specific WebAssembly component gets triggered. For example if there is a route such as /hello, then a user’s request to that route will execute that specific hello-world component.
In the context of the game, the faster we click, the more WebAssembly modules we spin up & down. This is why we call Finicky Whiskers the most adorable manual load generator. This is a brilliant example of infrastructure which is not only highly configurable in terms of usefulness but also provides the most frictionless experience for developers to actually action the interoperability between real WebAssembly binary execution, container usage, static HTML sites and build applications which will entertain the future of WebAssembly.
Learn more - Taking WebAssembly for a spin
If you would like to try Spin, there is a great quickstart guide which will help you set up a local developer environment where you can get Wasm-based web-applications and microservices up and running (in a few minutes) on your local hardware.
Fermyon contact details
We would love to hear what you are building and also help you out to ensure that you create WebAssembly applications beyond your wildest dreams.
Discord:
We have a great Discord presence. Please join us in Discord and ask questions and share your experiences with Fermyon products like Spin.
Twitter:
Following and subscribing to our Twitter is a great way to keep in touch.
GitHub:
We can be reached via GitHub.
Email:
Please feel free to Email us.
Become an insider
If you would like to “Become an Insider”, please fill out this brief form to get early access, deeper insights and other insider invitations.
We are hiring
We have a number of job openings available in areas of training, software engineering, developer relations, community management and more.