Serverless WebAssembly: Security, Speed … and Startup Times
Berlin’s “Rust and Tell” meetups feature monthly talks from industry experts. And last month saw a special presentation — about the advantages of compiling Rust to WebAssembly for server-side applications.
Speaking was Microsoft‘s former principal cloud developer advocate Ryan Levick, now a principal software engineer at Fermyon, promising to show his audience how WebAssembly is finally delivering on its promise of “small, fast, and secure-by-default server-side workloads.”
But it also turned into a surprisingly frank discussion about using WebAssembly in the real world of production — with a little help from Fermyon’s developer tool Spin for building WebAssembly microservices.
Levick’s talk covered all the pro’s — and some of the cons — that his audience might face, considering everything from startup times and server costs to the realities of porting Rust code.
And along the way, Levick also gave his audience something more — a snapshot of how far the WebAssembly ecosystem has evolved…
Lightweight, Sandboxed — and Fast
Levick noted WebAssembly’s “pretty small package sizes” — resulting in compiled Rust applications that tend to be “a few kilobytes of actual code.” And the code runs in a sandbox — which is obviously important for security.
But he went on to make the case that WebAssembly is speedy — in more ways than one. Levick sees server-side WebAssembly components starting in less than a millisecond. So in a serverless scenario, “you can start up hundreds of thousands of these things in the same time that you’d start up one container.”
He contrasted that with his own lived experience with Kubernetes, where it can take several minutes to boot up a virtual machine and install the code — and then even more seconds to spin up a container or a microVM. “That startup can be in the order of magnitude of seconds. Sometimes it’s even longer than your actual app runs…!”
And later in his talk Levick argued that the serverless paradigm also has a “cold start” problem. If there’s a temporary lull in accesses, caches obviously have to be refilled.
After his talk Levick reiterated his assessments in a follow-up “panel”-style discussion with Mainmatter’s Principal Engineering Consultant Luca Palmieri and SAP’s Jonas Dohse. In terms of “paid overhead,” Levick ranks them, from most overhead to least, in this order: VM, container, microVM, WebAssembly.
Other Advantages
Soon Levick had listed numerous other advantages for this server-side WebAssembly approach:
- When your customers aren’t making requests, “you’re literally running nothing” (other than a load-balancing frontend that listens for new events). “But as far as your business logic, what of that is running when you have no load? Nothing. Not a single thing…”
- As an aside, Levick added that “There’s a whole bunch more to say about why that’s also beneficial from a security perspective.”
- Levick reminded developers of another ongoing threat: being locked into your vendor’s proprietary platforms. “And then your boss says ‘Okay, we’re moving to Azure,’ and you have to re-write everything — because everything is targeted towards this proprietary serverless vendor solution!” (Levick, of course, works for a company whose product is open source.)
An audience member asked whether serverless paradigms handicapped the throughput of code, reducing its effectiveness for hashing or CPU-intensive applications. Don’t users lose performance-boosting features like multithreading or the data processing speed boost of SIMD?
Levick corrected him, pointing out that WebAssembly added SIMD support in 2021, but acknowledged that multithreaded concurrency is an “ongoing proposal that has not been accepted yet. So everything here that we’re talking about is single-threaded.” But in the serverless paradigm, Levick noted that short input-output operations usually aren’t long-running processes. Levick agreed that if you’re working for a cryptography startup, WebAssembly is probably not for you today. “If you have CPU-bound workloads that really are very CPU intensive, then yes… you might be missing out on the very edge of performance there.
“But I imagine 99 out of the 100 people here probably don’t fit that use case, and are probably doing a whole bunch of I/O.” So for those users, “you’re basically getting native level performance” — now with SIMD — albeit still missing threading, “for now.”
Porting Rust
Inevitably during the panel discussion, Levick was asked if creating WebAssembly binaries also required some rewriting of the application code. Levick acknowledged that’s true — today. “And we’ll take Rust as an example right now. If your application wants to use TCP sockets right now, you cannot use the Rust standard library to do that, because the Rust standard library doesn’t have support for WebAssembly sockets inside of it… The standard is incredibly new, and so we’re sort of at the very cusp of support…”
That means that in the world today, “yes you have to change your application in order to run it in WebAssembly. So I think today this is much more compelling for sort of ‘green field’ operations where you want to write, especially for a serverless-style architecture, from scratch. If you have existing code that you want to run it’s going to be a lot harder.
“Now fast forward two years from now, I think that will be completely different. We’re making changes to the Rust standard library for instance with the WASM 32, WASI Preview 2 target, which will introduce all support for this. And so your code will just compile and work as you’d expect it to. But that is not necessarily the case today.”
Expenses
There is one more drawback to serverless applications. “I worked at Microsoft. I talked to the Azure functions team. It’s really expensive to run these things… “They do a lot of work to make it not-so-expensive. But still, most of that cost gets passed on to us… That’s why in my experience, I’ve often not used serverless solutions, because it’s convenient, but it’s also really costly.”
But of course, that’s why his final slides addressed optimizing compute resources with Spin’s open source project for streamlining the deploying and operating of WebAssembly workloads in Kubernetes.
Levick said that SpinKube allowed users to run workloads Kubernetes workloads and “be able to get to a place where instead of one node running — I don’t know, a few, maybe 10 pods or something like that, and that’s kind of taking up all the room on that node — you can run, I think the max pod number in Kubernetes is set to like 256 or something like that. That’s Kubernetes’ limitation. We could run a lot more if we were allowed to.”
To save money and resources, users can then downgrade to smaller machines because “at the end of the day it’s just a whole lot more efficient.” The final slides were Levick’s way of reminding the audience that optimizations can have real-world benefits — and to quantify some of the power of WebAssembly, as well as Spin’s WebAssembly tools.
Levick even said that his team has done experiments where they’ve put WebAssembly apps into Kubernetes workloads — that are running on a Raspberry Pi.
WebReduce
- “Training AI on Your Own Data” — a solutions architect’s talk at the Southern California Linux Expo.
- Security engineer Ben Huber discusses what he’s learned from penetration testing — including common attack vectors and the finer points of user verification.
- How a new monitor technology can display a logo to those “outside the central viewing angle” to “increase the marketing value” of screens.
