DEV Community: Marius Kluften

Building Nebula - Chapter 2: Let's write some Wasm/Wasi modules with Rust

Marius Kluften — Wed, 03 Jan 2024 12:12:43 +0000

Starting to interact with WebAssembly modules

Some basic terminology

In my previous two posts I laid out about why and how I'm building a Rust webserver that can spin up WebAssembly modules on request.

You might be wondering:

Isn't this essentially a web server that spins up the wasmtime runtime in the background? Is that a Serverless Faas Platform? 🤔

... 👀

Yes. Yes, that is what I'm making. And I'm not 100% sure if the terminology matches, but I asked ChatGPT and I'm pretty happy with the answer.

Now that we've ensured that what I'm trying to build could be called a "FaaS Platform", even though it is a bit limited, without auto-scaling, monitoring, logging and more. For the sake of experimentation, some of these features could be implemented in some shape or form.

The dream feature is to be able to log power consumption readings from the server during each function call, and attempt to measure the "footprint" for each function, but we'll see how far Nebula evolves before the deadline in May.

"Hey, what even are Wasm/Wasi modules?"

Great question!

Previously I've been focusing more on the "why" and "how" of using Wasm modules in Nebula, emphasising on their quick startup times and compact sizes. What remains
is to delve into the nature of WebAssembly modules themselves.

WebAssembly, or Wasm for short, is akin to a universal language for computer programs. Imagine you wrote down a recipe in such a way that anyone in the world could understand and cook it without needing a translator. That is what I imagine Wasm modules to be for code. It allows programs to run virtually everywhere, and even though it was first designed for the browser, its design enabled it to be a perfect fit for servers as well.

Wasm was designed to run sandboxed in a browser, so how can we run it on the server?

This is where the WebAssembly System Interface, or Wasi, comes in into play. Wasi is a project that is built to package our Wasm code in such a way that it can interface with an underlying system, and this is what enables us to run Wasm on our servers and allow us to do server specific tasks.

In the context of Nebula, Wasm/Wasi modules are these recipes, ready to be whipped up and served in an instant on our server!

Some actual code

In the previous chapter, I concluded with a simple "Hello Simen" web page. It didn't even render HTML properly!

Now, let's dive deeper into the world of compiling Rust code into Wasi modules, which we will then run on Wasmtime. We'll start by coding our first function!
Given my academic backdrop for this prototype, I'll begin with a well known computational challenge: the Fibonacci sequence.

Why Fibonacci?

The Fibonacci sequence is a classic in computer science, where each number is the sum of the two preceding ones. Starting with 0 and 1, the sequence unfolds as 0, 1, 1, 2, 3, 5, 8, and so forth. While I haven't found a practical use for this during my career, it serves as a nice starting function for future benchmarking.

Nice sequence, bro

Here's my Rust code for generating the Fibonacci sequence:

// src/main.rs
fn fibonacci(size: i32) -> Vec<u64> { 
    // Create a vector (dynamically sized array-ish) to hold sequence
    let mut sequence = Vec::<u64>::new();

    for i in 0..size {
        let j = i as usize;
        // First two numbers equal their index
        if i == 0 || i == 1 {
            sequence.push(i as u64);
        } else {
            // Calculate next number in sequence and push to vector
            let next_value = sequence[j - 1] + sequence[j - 2];
            sequence.push(next_value);
        }
    }

    // println!("Help me");

    // Implicitly return the sequence
    sequence
}

// Print out the returned value from the function in the main function, the entry point to Rust programs
fn main() {
  println!("The first 5 fibonacci numbers are: {:?}", fibonacci(5));
}

[Source]

Once we build this with wasm32-wasi as the target, we get a Wasi binary file that we can deploy and run.

$ cargo build --target wasm32-wasi --release

    Compiling fibonacci v0.1.0 (~/nebula/functions/fibonacci)
      Finished release [optimized] target(s) in 1.07s

And then we can execute it using the Wasmtime CLI

$ wasmtime ./target/wasm32-wasi/release/fibonacci.wasm

    The first 5 fibonacci numbers are: [0, 1, 1, 2, 3]

Pretty sweet! But as you might have noticed, I added a main function in my main.rs file where I called the function inside a println macro call. That's not very "FaaS platformy-esque", the users would normally expect to be able to provide their own input and get something out.

Handling Input/Output with Wasi

I wanted to build my Wasi-runner library code to be as generic as possible, where I could simply provide the name of the function, which would then result in Nebula looking up if it has the corresponding module binary file present, take in the input, run the function and return the output.

I'm currently a level 2 newbie in the Rust ecosystem, with most of my skill points previously allotted to technologies related to JavaScript, like TypeScript, React and Node. This shift presented some challenges to me: building library code that allows me to generically craft Wasi modules, aligned with Rust's idiomatic practices, was quite an adventure.

During this journey I crossed paths with Peter Malmgren's blog, where he had written an article: "Getting data in and out of WASI modules" (link here). His insights, in which he laid out two different approaches to how you could achieve this back in 2022, proved to be invaluable. After experimenting, I found his first method, in which he relies on stdin and stdout for input and output respectively, to be particularly effective for my use case.

Treating WASI like a regular program

Because WASI was designed to be POSIX-like, it has access to resources like standard input and output, CLI
arguments, environment variables, pipes and network sockets. Peter explains it better than me, in his article, so if you're interested I would recommend checking it out.

This mindset shifted my thinking around how I could solve this input/output issue. And while there might be more idiomatic ways to solve it, I ended up relying on stdin and stdout for my examples.

// Import stdin and "attach" BufRead to the program
use std::io::{stdin, BufRead};

fn main() {
    // Create stdin instance
    let stdin = stdin();
    let mut input = String::new();

    // Wait for data to be passed to stdin
    stdin
        .lock()
        .read_line(&mut input)
        .expect("Failed to read line");

    // Attempt to parse it
    let parsed_input: Result<u32, _> = input.trim().parse();

    // Pattern match on the input. Default to 1 if the stdin was invalid 
    let size = if let Ok(size) = parsed_input {
        size
    } else {
        1
    };
    // Calculate the sequence and print it to stdout
    let sequence = fibonacci(size);
    println!("{:?}", sequence);
}

fn fibonacci(size: u32) -> Vec<u64> {
    let mut sequence = Vec::<u64>::new();

    for i in 0..size {
        let j = i as usize;
        if i == 0 || i == 1 {
            sequence.push(i as u64);
        } else {
            let next_value = sequence[j - 1] + sequence[j - 2];
            sequence.push(next_value);
        }
    }

    // println!("Help me");

    sequence
}

In this code, I await the input from stdin before the program goes further than line #7. Then I attempt to parse it to an u32 integer, if successful it will move on and pass the input to the fibonacci function. If it receives something other than a value that can be parsed to u32, it will default to 1, in order to simplify error handling.

If we build this again, it still compiles and compiles to a .wasm module.

$ cargo build --target wasm32-wasi --release
    Compiling fibonacci v0.1.0 (~/nebula/functions/fibonacci)
      Finished release [optimized] target(s) in 0.53s

Then we can pipe in our input as stdin and receive our output like so:

$ echo 10 | wasmtime ./target/wasm32-wasi/release/fibonacci.wasm > out.txt
$ cat out.txt
  [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

Cool! Now we're able to pass input to our Wasi module, and get output back! I realise that relying on side effects such as reading stdin and stdout might take
a hit on performance, but I have taken the same approach to providing input and receiving output to the same functions wrapped in Docker images as well, in order to fairly compare the two.

Closing words

If you're interested in seeing how the project was at the end of this blog post, I have tagged it as version v0.2 in my GitHub repo (Link here).

The Fibonacci example lives under the folder functions/fibonacci.

So, how can we expand on this way to interact with WebAssembly compiled Rust programs and expose them as functions for users of Nebula to call?

In the next chapter we'll look at adding the Wasmtime crate to the project and transform our "Hello Simen" web-server into a fully fledged FaaS!*

Stay tuned for Chapter 3!

**It will not be fully fledged for a good while, and I'm not sure if it ever
will.

Building Nebula - Chapter 1: Building a Prototype with Rust

Marius Kluften — Tue, 07 Nov 2023 10:37:52 +0000

The beauty of Rust and WebAssembly as the pillars for a new wave of Cloud computing

In the previous post, I laid out my motivations for Nebula - a FaaS prototype designed to explore the power of WebAssembly.

In this post we'll start diving into the "how".

A journey beyond JavaScript

The first 4 years of my career was dedicated to mastering the JavaScript ecosystem, where my primary quest was to enhance the user experience of every interface I developed. There's no doubt; JavaScript, with its ubiquity, will likely dominate the web space for many years. However, an encounter with the 2nd edition of The Pragmatic Programmer in 2020 nudged me in a fresh direction.

The book's tip #9, "Invest regularly in your knowledge portfolio", struck a chord. While the author advocated learning a new programming language annually, I ended up choosing depth over breadth, immersing myself in the world of functional programming through Elixir from 2020 to 2022.

But 2023? I decided to start a new side quest and discover what the 🦀 hype was all about. The video Rust makes you feel like a GENIUS by No Boilerplate sealed the deal.

I was, as no one surely says, "crab trapped".

Rust: More than just hype

My years navigating the vast sea of JavaScript have been both rewarding and challenging. The language, while very flexible, can occasionally feel like assembling a jigsaw puzzle with ever-changing pieces.

TypeScript improves this story by leaps and bounds in my day job, but for building Nebula - a prototype designed to swiftly spin up WebAssembly modules - I needed a more efficient and predictable environment.

Why is Rust great for the Nebula journey

Beyond my own personal reasons for wanting to explore Rust, I have compiled some of my reasons for choosing Rust.

Safety First: Rust's strict compiler and ownership model ensures that code I write for my prototype is less prone to common bugs, memory leaks and data races. These features will hopefully act as safety rails for developing my prototype.
Consistency and Reproducibility: For my research I need reliable reproducibility. With its predictable performance, I should be able to gather better data to compare later.
Streamlined Efficiency: My thesis requires a playground to rapidly iterate and experiment on. Rust's powerful concurrency model and zero-cost abstractions allow me to refine the logic of my prototype without worrying about performance bottlenecks. (Famous last words?)
A great WebAssembly story: WebAssembly has been a first class citizen in the Rust ecosystem for a considerable time. Furthermore Fermyon - the company that inspired my thesis - places substantial trust in Rust for their platform and SDK.

Building the first iteration

While the focus for my project is on building with Rust and run WebAssembly modules as functions, the road to getting there includes many steps. As of writing this, I already have a simple prototype working, and I'll try to lay out my journey to landing there.

Choosing the WebAssembly Runtime

For running Wasm modules on the platform, it's crucial to have a reliable WebAssembly runtime. There's a plethora of options available: Wasmer, Wasmo, Wasmi, WasmEdge, and Wasmtime to name a few. My research led me to notice that Fermyon had opted for Wasmtime. After a deep dive into Wasmtime, I was impressed by their well-documented Rust crate, allowing me to effortlessly integrate Wasmtime into my Rust project. A pleasant surprise was realizing that the final binary build didn't necessitate having the wasmtime runtime installed on my server.

Designing the Web Server Infrastructure

While the choice of WebAssembly runtime was crucial, the actual mechanism to serve and interact with these modules was equally vital. How do industry giants do it? Amazon with their Lambda, Google with Cloud Functions, or Microsoft with Azure Functions? Without the exact blueprint, I decided on crafting a feasible solution for my experimentation: a web server using Rust and Axum.

The backbone of this server includes a shared crate library. This library acts as the bridge between the web server and the Wasmtime runtime. The envisioned workflow is simple:

In my sketch below, I've drawn up a rough idea of what I want the platform to do in the first iteration.

User A calls the API (most likely REST API) with GET /api/treats/10 (/api/:module/:input)
Axum web server receives request, finds the corresponding wasm module "deployed" to the server from the module name, creates a wasmtime instance and provides it with the input.
The wasm module runs the function based on provided input and returns the output as a valid Wasm type. (In this case i32)
The web server responds the user with the value returned from the wasm module.
????
Neko is a happy dog, because he got 10 treats at (hopefully) BLAZINGLY fast startup speeds!

Humble beginnings

My main.rs file looked like this in my first iteration:

#[tokio::main]
use std::net::{IpAddr, SocketAddr};
use axum::{routing::get, Router};

async fn main() {
    let app = Router::new()
        .route(
            "/",
            get(|| async { "
              <!DOCTYPE html>
              <html>
                <body>
                  <div>
                    Hei Simen!<br><br>Hvordan går det? :)
                  </div>
                </body>
              </html>" 
            }
          ),
        );

    // run it with hyper on localhost:3000
    axum::Server::bind(&SocketAddr::new("127.0.0.1", "8080"))
        .serve(app.into_make_service())
        .await
        .unwrap();
}

The root page now looks like this:

While maybe not an technically impressive web page, and I'd expect more from my self after 6 years of web development, I still had managed to get a web server in something other than Node and Express up and running!

Smells like victory!

Closing words

Now you might be wondering: "Wait. What happened with steps 2 through 6? Neko ain't getting no treats with this rudimentary Hello World web server?? What gives??".

Great question! We'll explore that further in the next chapter!

See you in the next instalment!

Building Nebula - Prologue: A beginning

Marius Kluften — Thu, 19 Oct 2023 10:53:04 +0000

A Function-as-a-Service platform powered by WebAssembly, built with Rust

By now, you might have stumbled upon this well-known quote:

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
That's how important it is. Webassembly on the server is the future of
computing. A standardized system interface was the missing link. Let's hope
WASI is up to the task!
Solomon Hykes, founder of Docker

It's a bold statement that has been circulating ever since. I'm currently exploring this vision, where I've embarked on an adventure to build a FaaS prototype that exclusively runs WebAssembly modules. The goal? To discover the potential computational and energy efficiency such an approach might offer, forming the backbone of my master's thesis research.

In essence, I aim to compare the performance and efficiency of predominant FaaS platforms - such as AWS Lambdas, Google Cloud Functions and Azure systems - against a system that rapidly initialises Wasm modules, executes the underlying function, and promptly shuts them down.

Finding my Master thesis topic

I'm building this prototype in order to perform some experiments for my Master's Thesis as part of my Master's degree in Programming and System Architecture at
the University of Oslo. I initially started on this degree back in 2017, after achieving my bachelor's degree in Computer Engineering from OsloMet, but decided to jump off after the first semester when I got a job offer for working fulltime
as a ServiceNow consultant.

Ever since then, I've had 1/4th of a degree completed, and decided to pick it up again in 2022 and attempt to finish it part time. At UiO there's a clear preference for "long" master theses, meaning that 50% of your degree is made up
of the thesis itself. In order to motivate myself to this undertaking that would occupy most of my free time, I decided to focus on what technologies I would like to see myself working on in the future, and was lucky enough to land a
thesis project where I could dive into the Rust and WebAssembly ecosystem.

I can attribute the initial idea for my master's thesis to the podcast episode "Fermyon with Matt Butcher" from the Rustacaen Station Podcast. Fermyon is a Cloud company that are heavily invested in the WebAssembly space, and in the episode Matt Butcher, the CEO of Fermyon, tells the story of how Fermyon came to be, and why they decided to build a Cloud platform that only allows developers to run programs that can be compiled to WebAssembly. In his explanation, he mentioned that they observed rather insane startup times compared to more typical container based function-as-a-service offerings out there, going from comparable service in a Docker container taking 300ms+ just to start up, down to sub 1ms startup times for a comparable Wasm module delivering the same functionality.

Furthermore, as they advertise on their own
webpage they saw that with Wasm modules they were able to achieve image/binary sizes down to ~1% of a comparable service packaged in Docker, from 230MB -> 3.2MB!

Why purse a FaaS prototype?

These metrics presented by Fermyon and the WebAssembly community are nothing short of remarkable. They've summarised their vision in the "third wave of cloud computing", with Virtual machines being the first wave and Containerisation
(Docker) being the second wave. This begs the question: What kind of energy savings might we achieve if the industry leans more into these efficient cloud technologies?

Guided by this curiosity - and with invaluable insight from my university supervisors - I formulated the hypothesis for my thesis:

It is possible to develop a Pure FaaS platform that scale to near-zero
resource usage, using WebAssembly modules

It's an ambitious objective, no doubt. Yet, this broad premise provides me ample space in how I end up building the prototype this fall. A cornerstone for this prototype? The principle of "pure" functionality.

Building a "Pure" FaaS

You've probably noticed the emphasis on "pure" in my hypothesis. In order to develop a prototype I can start experimenting on within the time-frame of a Master's thesis, I decided to scope it down to explore a FaaS platform that
operate on pure functions.

For those unaware of what a "pure function" is, it can be defined as such:

A pure function is a function that, given the same input, will always return
the same output and does not have any observable side effect.
Mostly Adequate

This principle of purity assures consistent output for consistent output, a quality that opens up for interesting experimenting. This will allow me to explore some interesting orchestration and caching patterns for functions
deployed to the platform, much like a hypothetical example illustrated below:

Naturally, building such a dynamic system has its challenges, and there's always a risk of overextending the scope of my thesis. Thus, my focus might lean more towards experimenting with pre-defined functions on the platform. We'll see!

If you've journeyed with me this to this point, I really appreciate your time and interest! I'm excited about sharing more technical details down the line, and you can read more when my first chapter gets published!

Link to repo: https://github.com/brehen/nebula