Rust Programming Language Rust Linz, 4 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building microservices with WebAssembly, Rust, and Spin - Radu Matei - Rust Linz May 2022

Description

Spin (https://spin.fermyon.dev) is a framework for building and running event-driven microservice applications with WebAssembly (Wasm) components.

With Spin, we’re trying to make it easier to get started with using WebAssembly on the server so that we can all take advantage of the security, portability, and speed WebAssembly provides when it comes to running microservices.

In this session, we will introduce the WebAssembly component model, and how Fermyon uses it together with Rust to create fast, secure, and portable microservices.

A

Thanks hi friends, I'm radu I work at fermion, I'm really passionate about webassembly, distributed systems, artificial intelligence and the intersection between those things. You can find me on the internet most of the time when I'm not around computers, I really enjoy classical music cycling bubble tea.

A

This was my yesterday's bike ride, which I really really enjoyed, and uh today we'll have a look briefly at what webassembly is uh the new webassembly component model, which is a new thing that is being proposed at the w3 level, and then I will see how spin uses rust and the component model to build a framework for microservices with frost and webasseme.

A

So before anything else, I'd like to briefly touch on what web assembly is. There's a lot of hype around webassembly these days and it's it always helps to go back to okay. What actually is this thing, and specifically it's a binary instruction format for a stack-based virtual machine in familiar terms? It's basically a compilation target that uh it was initially used to bring new languages to the web.

A

So you can compile your c or c, plus, plus rust, c sharp, python, ruby and a host of other languages that compiles webassembly and bring that to the web, and that generates a binary format which runs in an isolated sandbox in your browser and in the browser web assembly has been around for around five years and it has enabled a lot of applications from running zoom in your browser to running windows, 95 to slightly more useful things like autocad photoshop, google earth things like that, and the big promises of webassembly are platform and cross architecture.

A

You don't really want to uh be to open a web page and then be prompted to oh press, this button to access the linux arm website or press this one to access, mac, x86 or things like that. You want to have true cross-platform across architecture.

A

You want the really compact binary size. uh You really don't want to wait around to download hundreds of megabytes and associated with that fast startup times. You want to access your page instantly and have it interactive and very, very important. You want an isolation sandbox, so you don't want the code, that's running in tab, 1 to access your banking application on tab 2.

A

Nor do you want uh code from any web application to access your system, so isolation is extremely important on the web and as we look at the things that uh webassembly is promising and how they uh relate to the browser, we kind of start thinking about well the same things that make it appealing in the browser. Cross-Platform cross-architecture compact, binary size, isolation.

A

Those actually make sense outside the browser as well. So we really really want to explore using webassembly for server-side scenarios, and this is where the web assembly system interface comes into play, which aims to standardize the execution of webassembly outside the browser and um and basically the wazi lets you access file, the file system, networking environment variables, all the things that you would normally use in the pos xe system right.

A

But um I would like to introduce a very new proposal which uh you can find on. The internet called the webassembly component model and um the way I usually like to talk about it is using an operating system analogy and basically, if the core webassembly specification defines some low-level cpu instructions like I 32 loads, i32 store ad things like that, and on top of that, wazi models, input, output, interfaces like file systems and networking.

A

What we need is essentially a model that defines how processes are started and how they communicate with each other, and this is exactly what the webassembly component model is trying to address, essentially defining a new binary format that enables cross-language composition.

A

uh It enables a wide range of use cases that we'll look at in a minute, and personally, I think this really represents the future of webassembly everywhere.

A

The component model is these: are the stated goals of the component model to enable scenarios like host embedding components. uh We hear people describing web assembly as the last plugin model you will ever need ever need uh embedding uh plugins in all sorts of scenarios, from databases to uh serverless platforms, the scripting environments, pretty much. Every everywhere you would need a user-defined function or user-defined functionality.

A

Webassembly might be uh suitable for those scenarios, particularly when you want to have isolation between those environments.

A

Another big goal of the component model is to enable component composition so, for example, using high performance code in uh from your javascript right, reusing, a a high performance code between low level c or component dependencies from a registry and composing those uh through, for example, dynamic linking when you want to define some components from the from a registry and dynamic building those at one time at its core.

A

uh A a web assembly component essentially is a way to put together multiple core modules and components and define a strongly typed interface that the outside world can use to interact with your website component, and I think it really helps to have a look at a simple uh example. um Basically you're able to describe your functionality using an interface. This is the width format for webassembly.

A

This is currently being standardized and basically you're able to define functions, instructs records and results pretty much similar to what you would do in your regular programming language, and then there is tooling that generates bindings from for either implementing that interface and building webassembly components or consuming that interface from other web components. And, of course, webassembly tooling, is very, very popular in the rust ecosystem and all the things that I'm going to show.

A

You are both written in rust and also have really good support for using rust to build components, and essentially, if you want to implement this particular interface in in rust and generate a webassembly module from your rust code. There's a tool called with bind gen with being the format of the of the interface that generates uh this rust trade for you that you can then implement in your code so basically uh generate the trade using with bind gen and then implement this in your codes.

A

If you then build this, uh this rust uh program and compile it to wasm 32w those interfaces get exported as regular webassembly exports and then the one other thing that I would note here is that, as I mentioned, the webassembly component defines a way to to have a strongly typed interface to accessing functionality inside your webassembly component and adapting values across that interface. Boundary is done using something called the canonical api, which essentially is a way to adapt a function, adapt that high level values from the outside world to the representation that your component uses.

A

So an example for where you would need this is strings. Javascript uses the wtf16 representation for strings rust uses dtf8 the adapter functions would basically describe how to adapt an incoming value from one format to the other and of course the second aspect of this is consuming um consuming an interface, and you can.

B

Also, do that using the auto generated.

A

Bindings uh done by with bind gen, and this was after you compile your program. This results in the functions from the interface are being just regular, webassembly imports. So, if you're familiar with the webassembly text format, this is just a regular wasm import.

A

And this is where, having looked at webassembly, the new web assembly component model. This is where we are starting to have a look at spin, which uh is a project that we recently launched. uh Basically spin is a framework for building and running benjamin microservices, using webassembly components. It's built entirely on the website component model that we've seen previously uh and it's an open source project that whose goal is to make it really really easy to build and run your first webassembly microservice, and we have excellent support for uh building those microservices in rust.

A

Of course, spin is built in rust as well, and uh the primary thing we will have a look at is building webassembly components that can handle http requests, but we'll see in a bit that spin actually does a lot more than just http and it's a multi-language framework. It has robust support for sdks for rust and go, but you can write an http handler in any language that compiles.

A

uh If you can compile your uh codes to the webassembly system. Interface, 2032 azi, then that webassembly module can be used as an as a spin component, and we really think it's a it's. A really really simple way to write fast and secure microservices using webism.

A

You have a very simple application, manifest that describes what type of application you have, in this case, an http application, and then you have a list of components.

A

In our case, we have one component, called frost dash lens, define the webassembly module that will handle this component and then sum trigger configuration in our case, which route is this component supposed to handle, and in our case it should handle all all requests coming to this application, and then you have a simple way of defining how you want to actually build and compile the web assembly modules for this component and, as you can see, we're just using the regular cargo tool chain.

A

So now that we've seen the application manifest next thing is: what do we actually write? We do a spin new and then this is what gets generated for us. This is an entire spin http component.

A

We have a hello world function that takes in an http request and returns a result as an anyhow result using an http response. The http requests and responses are basically coming from the rust hdb crates from the upstream crate. That's used in all http uh frameworks in rust, and the only notable thing here is a proc macro, not another another type of macro that alvin showed us. This is a slightly different proc macro attribute that we'll see in a minute and basically it takes in the web.

A

The http requests the incoming requests and then returns the response uh in inside your function handler you can do anything that compiles the webassembly and uh let's have a look at running one of these from scratch.

A

Spin, which is the the cli, has a list of templates that you can either use the built-in templates like http, rust or http go or you can build your own.

A

We will do this menu and write them. A new http, rust components.

A

Write a description.

A

And this generated a very simple uh rust project for us: let's open that up.

B

Sorry to interrupt you, um we don't see, the screen was frozen. ah Now it works again. We saw we heard you typing and you were describing something, but the terminal was somehow froze. Now it is fine again. It was very glitch.

A

Okay, thanks uh yep, the the thing that the spin new command generates is a very simple uh in the case of a rust template, a very simple uh rust project. We basically have a cargo tommel source directory and the only added thing is a spin dot tumble so opening that in ds code we see cargo tumble.

A

We have a package, author's cdy, lib uh library type that generates a web assembly module for us and then a bunch of dependencies anyhow http, as I mentioned, and then the spin sdk and with bind gen tooling that takes a web assembly interface and then does some behind the scenes magic.

A

uh The other uh part of a spin application is the spin manifest, which is exactly what we saw before an http application and then some component configuration the actual code is just that right. It's it's. A one function annotated with the http component, takes the http in the http request and returns. The http response, and the request and response, as I mentioned, are basically just http requests and they take an option of bytes. Nothing, nothing! Fancy there.

A

What we can do is execute the build command for of our application, which just calls cargo builds using the wasn't. 32 target successfully run the build command, and then what we can do is do a spin up, and this will start a web listener on localhost and basically, all requests that are coming into this particular server will be handled by our component. So what we can do is curl and then see hello fermion.

A

Let's do a slight change to that hello, rust lens, save that and we can do a spin, build dash dash up, and this will recompile and actually restart our application, and this is hello, rust lens now. I I mentioned a couple of times that our goal with spin is to build a way to help you create and run really really fast applications. So, let's, let's run a small load test on our application for 10 seconds.

A

This will basically bombard the web server with five concurrent connections for 10 seconds and hopefully, if everything works well, we'll see that on average for almost 200 000 uh requests, the average response times was 260 microseconds.

A

So basically, this is the the uh the base, uh the base scenario where the component doesn't actually do a lot, but you can what happens behind the scenes is spin will take the webassembly module and for each new request it will instantiate it execute the rust lens function and then return the response back to the client. So within those 200 microseconds spin does a lot of things and the more the most important one is for each new request. You get a fresh web assembly instance.

A

That's entirely isolated from all the other requests that are executed on your in your process on your machine.

A

So um we at the beginning, we talked about the component model and spin uses the component model for everything. All spin components are defined using webassembly interfaces and all external services are defined as web assembly interfaces. So by default in webassembly you don't actually have access to anything outside of your module. So if you want to use anything from uh files to making outbound http connections to connecting to a database, everything has to be explicitly allowed and spin does that using the component model uh for an http request.

A

Basically, it's fairly similar to what we saw in the in the cache interface. We have a handle, dash, http, dash, request function that takes a request and returns a response, and if we look at the proc macro attributes, this is basically uh what spin does behind the scenes is. If we remember the uh how you can use the rust tooling to uh to generate a webassembly module that implements an interface.

A

There is a trait that with binding defines for us, and then we implement that for our particular uh implementation. This is exactly what happens with spin and http. This is using the upstream, uh with binding tooling, to take your function that you define as the http component and adapt that to be the entry point for a web assembly component. So this is entirely compatible with any any tooling. That's uh that's going to be compatible with the wireless md component model and and of course we do that for everything else.

A

Not just http uh spin has built-in support for handling pubsub with uh with redis for every new message that comes in a redis channel. uh You can write a function that implements this webassembly interface, which is fairly similar to the http. Instead, it takes a message, payload and returns uh unexpected error, and then we are working on building a trigger uh timer trigger for prawn jobs, and things like that. That takes a clock event and returns a basically a string.

A

Hello world is great: we've seen hello world in a dozen different languages for a dozen different projects in the webassembly space, but we wanted to build something a bit more and uh if you go to fermion.com right now or spin.fermion.dev, which is the website for spin uh both of those are powered by webassembly, microservices and spin, and they have been serving hundreds of thousands of web assembly modules in the last couple of months, so we're actually dog footing the things that we're building and uh every time you visit, fermion.com you're actually spawning a bunch of webassembly modules that spin executes and besides that, we've built something called a manual load generator called finicky whiskers.

A

So if you go to finicky, whiskers dot com right now, you will see an application. That's built on top of spin that has a bunch of webassembly microservices that are used to showcase how to how to generate load and how to do, for example, connect to redis and things like that. So if you go to finickywhiskers.com.

A

This is the this is the website.

A

uh If you start, you basically have to feed uh with slats, which is one of our teammates cats, which was a very, very picky eater and every time you every time you press the button and it's the right food that that slats desires. You have a incrementing uh incrementing score and you have this application running in our cluster.

A

On top of nomad with the microserve webassembly microservices that are running behind the scenes, uh you can play that right now, if you want, but essentially it's it's designed to to showcase how we think about microservices and containers in the in the future, and the game essentially is a static website that we've seen and then six webassembly microservices, with redis running as a container in the background, and as you click the buttons to feed the cat, we're executing requests using spin and we're instantiating a new webassembly module on each new request, the faster you click, actually, the more webassembly modules you start.

A

So, if you are really really fast, you can uh you can get a higher score and it's essentially it's just a load generator. That happens to be slightly more adorable than your usual cli load generator. Essentially, as I mentioned, there are a couple of micro services. Some of them are http based. Some of them are triggered by redis pub sub. All of them are using external services, external persistence, using redis, using the key value store and, for example, for a played game that scores around 100.

A

You actually instantiate over 250 web assembly instances and as we've seen in our load uh test earlier on the cli each of those starts in around 200 microseconds, which uh is why we don't have a problem serving hundreds of thousands of them in short periods of time. You can try it out at finickywhiskers.com and you can have a look at spin on github.

A

So from me on github.com.fermionspin, and I would encourage you to have a look at our documentation which, by the way, is also served using spin.

A

Finally, I really want to uh say a big thank you to the webassembly community. None of the work we've seen would be possible without the amazing people working on standardizing and implementing webassembly and in particular to the people building uh wasn't time in the component model and all the tooling behind the component model. Any questions.

A