Session

Server-Side Wasm: Today and Tomorrow

What You'll Learn

1Hear about Suborbital, what it is and what it does.

2Learn about new ways of using Wasm on the server-side.


Wasm has already started making waves in the web development community, enabling developers to run code written in various languages at near-native performance. There is so much potential for Wasm to enable similar capabilities outside of the browser, which is what I explore in this talk. Docker made it easy to run full-blown server applications in a portable way, but Wasm has the potential to take this even further; by enabling developers to write individual serverless functions in the language of their choice, and load them as hot-swappable modules.

I explore Wasm as it is today, and the capabilities that Wasm will bring us tomorrow. I'll use the Suborbital Development Platform to illustrate how Wasm modules can be used to compose powerful server APIs, and talk about what the future of extra-browser Wasm might look like. I discuss how Wasm will enable highly modular code, increased security and performance, and how it intersects with Docker and the Serverless ecosystem.

This is a client-side track and we're talking about server sidewise. How do these things work together?

WebAssembly was born out of the desire to run a more native-style code in the web browser. But what interested me in the technology from the beginning was the fact that it is a portable cross-platform assembly format for compiled code. I thought back then that sounds like it could be useful in other contexts, but I brushed it off because they were building it for web browsers. Then maybe a year or a year and a half ago, I started seeing people using it outside of the browser. These other runtimes started to pop up, not just the V8 engine in Chrome. It was things like Wasmer and WAVM. People started talking about it in that context. I said, OK, this aligns a little bit more closely with what my brain went to when I heard about it originally. And so I started looking more into it. I went to a couple of conferences, the WebAssembly Summit and stuff like that. People started talking about how this portable format could be applicable to the server side. Things like WASI, the WebAssembly System Interface started popping up; things like waSCC, which is an actor pattern framework for Wasm. This really started to solidify in my head that, OK, in our quest to simplify server-side development, with people moving to serverless, people moving to functions as a service and those kinds of things, we could we could use WASM as a lowest common denominator for all of these different frameworks. It could allow us to build the portable, simplistic feature that we were hoping to have. About a year ago, I started working on the Suborbital platform, which is a set of libraries and tools. My end goal is to have that plug and play Wasm server-side experience as a developer, because I don’t think you should have to care about the container runtime and the virtual networking and all those sorts of things. If you want to just deploy a couple of API endpoints, that's just so overkill. So I wanted to come up with something that was vendor agnostic, as language agnostic as possible. It could give a whole bunch of extra performance and security benefits. So I started working on this project, and it's coming to a head. It's very close to being ready for real world use, hopefully by the time this airs at the conference, it will be in its first alpha release. And I'm pretty excited.

Are you talking about functions as a service deployed across a platform that leverages Wasm? Are we talking about web-tier stuff? Not web-tier stuff? What's the context?

My particular background is in web service development, APIs, REST and event-based stuff. I have built the framework around that as the primary use case. Writing composable functions is really what it comes down to. You can have your business logic encoded in these very small and very pluggable little functions. And the way that my project surfaces that is in a declarative manner. you dictate “for this given input, here is a composition of functions that are chained together to handle that”. Those functions can be written in a bunch of different languages. It all goes down to Wasm, all scheduled by the job scheduler. At the end of the day, you don't need to care about the topology of the network, you don't need to care about the container runtime, you don't need to care about Kubernetes, you just need to say, input runs functions. That's what it boils down to.


SPEAKER

Connor Hicks

Lead Developer - Product Discovery @1Password

My name is Connor Hicks. I live in Ottawa, Canada, and I lead the Product Discovery team at 1Password. I have been fascinated by distributed systems and web service architecture for a long time, which led me to build the Suborbital Development Platform with the goal of enabling developers to build robust web services as easily as possible. I also love woodworking, camping, and my dog!

DATE

Thursday Nov 5 / 09:00AM PST (40 minutes )

TRACK Clientside: From WASM to Browser Applications ADD TO CALENDAR Add to calendar SHARE

3 weeks of live software engineering content designed around your schedule.

Don’t miss out! Save your seat now

Register
TOP