Is WebAssembly the Secure, Efficient Alternative Everybody was Waiting For?

Transcript

Olimpiu Pop: Hello everybody. I have in front of me, Laurent and Geoffroy, to discuss something a bit futuristic, if you want, WebAssembly Kernless and what the benefits might be that this might bring. But before that, Laurent and Geoffroy, can you please introduce yourself?

Laurent Doguin: Sure. I’ll start. My name is Laurent Doguin. I’m the director of developer relations at CouchBase. I write stuff about CouchBase, I talk about CouchBase, and I speak to our customers who do fancy things with WebAssembly and sometimes serverless, which is why I’m here today.

Geoffroy Couprie: Hi. I’m Geoffroy Couprie. I’m a Rust engineer at Proton Mail. I’m using WebAssembly daily and I’ve been in previous jobs, so it’s been a pretty significant part of my work for years now.

Olimpiu Pop: Thank you. But let’s take a step back and start from the conversation that got us here. Laurent, it has been some time since we met in London, but still that conversation was quite interesting and you presented something to do with serverless and WebAssembly. Can you give us the gist of that presentation and how serverless and WebAssembly fit together?

When you are running a functionality service, you are continuously running pieces of unknown code [01:23]

Laurent Doguin: Yes, so I was at QCon in London in April, I think, and I did a presentation about how the new Wasm component model was the fastest friend, a fast functionality service. The gist of it is that when you’re building a serverless platform or functionality service, it means you’re basically running untrusted code. And running untrusted code, we’ve had a different solution for this in the past. People have been isolating code in a variety of ways. The main reason is that you need isolation because a process can do weird things to your kernel, basically. Let’s say you run two processes on the same machine, on the same laptop, and one process does something completely stupid, like, for instance, rebooting the machine. Because why not? It could. Then you’ve lost everything, so you need to isolate those processes.

The metaphor I usually use is double dipping, which is also in my talk. There’s a scene in Seinfeld, the TV show, where you get someone taking a chip and putting that chip into a guacamole bowl, and then he eats the chip, and then he dips the chip again. So he’s sharing his microbiome, his microbes, or maybe his good bacteria, who knows, with the rest of the people that will use that guacamole bowl.

Now that’s perfectly acceptable if you are doing this with people you trust 100%, maybe even 110%. You could do this with your wife. You wouldn’t likely do this at a funeral with lots of strangers, which is precisely what happened in that TV show.

When you share a kernel with two processes, that’s what happens. You’re basically using the kernel as a guacamole dip and in a variety of ways to make sure, let’s say, to mitigate things that could go wrong. You could start by first running only one process on one machine, and then you could maybe isolate that process by running into what we call virtual machine. A virtual machine is an isolation level that’s provided by the CPU, by the hardware stack, and it’s basically telling you that you are in a fully isolated environment.

When we talk about virtual machines, people tend to think about VirtualBox or VMware. People tend to think about very slow thing that takes 30 seconds to boot. We’ve gone a long way since then. You can run a virtual machine quickly and efficiently using KVM and microVM frameworks like Firecracker. I’m sure we’ll discuss this further later, but that was the original way people used to isolate things.

And then something showed up. It was called Docker, or Docker was based on LXC. It’s not virtualisation. It’s called containerization. The good thing about containerization is that it’s very easy to use, much easier than VMs. The point with containers is that they’re not as isolated. You’re still sharing the same kernel. There’s no hardware security enforced by the CPU instructions.

So, containers are great, containers are popular, but it’s not as safe as VM. And so people started to add more on top of this. They’ve used things like gVisor, Kata containers. They try to add more solutions to make containers safer. And at the same time, the VM people add more solutions to make VM more lightweight and faster.

So that’s sort of the runtime solution you have right now when you want to create a safe environment to run code that you don’t know. And that’s without talking about WebAssembly. And the whole part about this talk was to introduce WebAssembly as a solution for that.

Olimpiu Pop: Great. So, trying to put everything you said in a nutshell, the biggest problem as an infrastructure provider is that you’re running code that other people are putting there. You don’t know what you’re running. So, in order not to contaminate it, you need to isolate it. And there are multiple solutions to that. We can look at the history, but WebAssembly is coming now into the frame as a more lightweight, faster-to-start and stop solution, right?

Laurent Doguin: Yes, absolutely. Spike code that runs on a virtual machine, basically, and that virtual machine gives you access to very few things. It basically gives you access to a memory space that you have no way to get away from that memory space unless it’s explicitly set by the virtual machine, by the runtime. So it’s extremely isolated in theory. The only thing, it’s allowlist security model. By default, you cannot do anything, and then the runtime must tell you what you are supposed to do and must tell you how you get away from the very, very strict boundaries that you were given at runtime when executing that function or that bytecode.

Virtualisation solutions: VMs and containers [05:35]

Olimpiu Pop: But does serverless actually exist, because in the end, there is always a machine behind the scenes, regardless of how we have it in the infrastructure. And I think that was the use case that you two worked on in the past, and because that sounded more like that, more in terms of infrastructure. So maybe let’s look into that a bit more.

Laurent Doguin: Right. Because it wasn’t just about serverless, it was about functions. We were running a platform as a service company, and we were running other people’s code. And most of the application code was running in containers or running in VMs, mostly VMs, microVMs. But we needed to go a little more granular, and that’s where Geoffroy came in with the idea of basically re-platforming or creating a function as a service on top of a new technology, which was not a VM or not really, but which was much smaller.

Geoffroy Couprie: Yes. So the interesting point was that at the time, in 2018, I went to look at the WebAssembly spec when I started using it. The interesting part when looking at that spec is that it was not meant for the browser; it was a pretty generalist platform. I got the idea that, oh, maybe that could run on the server side, and I went to just hack on that for three days. Perhaps I can make some WebAssembly code run on WebAssembly interpreter and have it execute a web app, a small web app.

And that was running pretty well. The thing that was missing was excellent isolation at the time we were both working at Clever Cloud, a French web hosting company. Virtual machines were in the DNA of the company. Everything was on virtual machines.

I got the idea after having messed with Hypervisors a few years back that maybe I could just load the WebAssembly generated code taken from the bytecode and compiled to machine code and run that directly in a virtual machine without even an operating system because since the WebAssembly runtime has to expose exactly what the app needs and there are no other dependencies, then maybe I can specify exactly what the virtual machine exposes. We don’t have to reveal any kind of weird hardware or anything, just precisely the API we would need.

And that’s where the idea came from.

Olimpiu Pop: That makes sense. So what were you targeting? What were the problems? Everything was from the perspective of the security, or it was also in terms of optimising the usage and making it, I don’t know, maybe more profitable?

Geoffroy Couprie: There was security for the virtual machine part, as well as performance. What people are always looking for in serverless platforms is how to run the cheapest way a small piece of web app, even cutting up an app into various elements that will run concurrently. So maybe this endpoint is called a lot and we need to provision some machines, but this one is only called once a month, so maybe it’s on the scale to zero applications. That’s the kind of play people like to do with serverless.

And so the idea was that, oh, can we make the cheapest way to run code safely in WebAssembly? That was a pretty huge bet. A few things needed to be done. Like, how can you make a virtual machine boot extremely fast, even faster than how most containers boot? There were a lot of freaks to get that, but I don’t know at which point they are starting now at Clever Cloud because the project still hasn’t shipped. But I was pretty close to one millisecond at the time to boot a virtual machine and have running code inside.

Olimpiu Pop: That’s impressive. Where did you get started? What was the initial time of booting the machine just to get the factor of the improvement?

Geoffroy Couprie: That was, like taking a virtual machine and taking it down to the smallest elements. So, a virtual machine is a virtual CPU. You ask the KVM API in Linux, “Make me a virtual CPU”. You provide some buffers and say, “Oh, here’s your RAM. That’s where you have your memory, and this part is executable, this part is not, this part is writable, this part is not”. You decide exactly what you want. And from there, you just decide that you do not make any hardware. You don’t need a network card. You don’t need anything. You just need a way to communicate with the host.

And for that, I used IO ports, which was the simplest way to communicate. I could have created a Virt I/O device similar to how most distributions can create a Linux VM that works on VMs right now. Now, if you want to run Ubuntu or something on the server in the virtual machine, the hypervisor is not emulating any real hardware. It just provides a Virt I/O device, and the guest knows that it’s running on the hypervisor. And so it’s just saying, I want to send something on a network over there and it’s not talking to a real network card.

But even that was not needed; the simplest way to load code was sufficient. And from there it’s about booting the virtual CPU. So a fun fact is that even for a virtual CPU, you have to do the boot sequence like you do with a normal CPU, where it starts in 16-bit mode ,and then you have to make a few instructions to move to 32-bit mode and then to 64-bit mode. It’s like you start in the ’80s, and then you have to go into the future feature by feature progressively.

Olimpiu Pop : So it’s back to the future whenever you’re booting the machine, right?

Geoffroy Couprie: Yes. You have to do all of that very, very quickly. But once you have the VCPU and the RAM, and you have loaded whatever you wanted in the buffers, then it’s there. So you don’t have a boot sequence for the entire OS at this point because you don’t have an OS. You can just point to the part of the buffer where you put the code and say, “Hey, execute from there”. That’s it. The VCPU will just start executing.

Olimpiu Pop: So if I understand correctly, by the end of your optimisation journey, let’s call it like that, you’re going to boot in one millisecond, right?

What was the initial time at which the machine booted? Okay, well, the virtual machine booted.

Geoffroy Couprie: I think it was around 20 to 30 milliseconds at first.

Olimpiu Pop: Okay. Wow, that’s impressive. It’s a 30x improvement. Yes, kudos for that.

And what did you use at that point? Laurent was mentioning earlier, Firecracker, or maybe you can single out a couple of the tools that you came across at that point.

Early days of WebAssembly on the server [12:05]

Geoffroy Couprie: Yes. So at that point, it was pretty early. So if you wanted some good Rust bindings to the KVM API, you had to go; there was a small library you could fork from the Chrome OS open source code. I started from there. I did a few patches. And a while after, some people started the Cloud VMM project in precisely the same way, starting from this small library, and I think Firecracker ended up using Cloud VMM, too. So Firecracker is this hypervisor that’s made by Amazon, I believe, and its entire design is to boot a Linux virtual machine faster and in a very safe way. So it’s using the same tools.

Olimpiu Pop: So this was probably the early days of this movement, let’s call it. How are things now?

Geoffroy Couprie: Now I’d say there are a lot of existing actors. You may have seen some projects on crosslets, which were some WebAssembly machines that would run in the Kubernetes cluster. There’s been Fermyon, that’s an entire company around that. Microsoft is also doing with the Hyperlight project, basically the same thing, combining WebAssembly code with native code, running that on very light virtual machines. So yes, they are making pretty good progress there as well.

So I guess the pattern is coming into mind. Before we had the idea, we realised that if you want to sandbox something, you need to use all the tools Docker uses. But now virtual machines are becoming very easily accessible and hackable, so people are looking at what they can do with that.

Olimpiu Pop: Yes. I also think that last year, I saw a lot of content during the KubeCon about how they are marrying Kubernetes with WebAssembly to get more speed. I had the earlier discussion, I think around April or May this year, with one of the guys who put together the connectors for WebAssembly and Kubernetes. And what he was saying is that for him, the frustrating part is the fact that you have a pod that starts in, I don’t know, let’s say seconds, and then you have WebAssembly that is starting in seconds, and then it’s pointless because you have to wait for the pod itself. But I think there is a lot of progress being made in this direction.

Laurent Doguin: Yes, that’s kind of what sparked my talk about WASM at KubeCon. I’ve been working with the folks at the CNCS WASM Cloud, and they’re essentially trying to create an API similar to Kubernetes’, but with WebAssembly binaries instead of pods. And so they’re telling you to recompile, rewrite your application to WASM directly so that you don’t have that overhead that you would have using traditional Kubernetes. You could have a compatible API but manage WASM binaries.

Olimpiu Pop: That makes sense. Especially that a lot of the more efficient languages these days have a target to compile into WASM, so that will make things a lot easier, especially since you don’t have an intermediary step. From the compiler itself, you can just wrap it and have it out the door.

But looking at the ecosystem, what do you think it’ll make things even better? We are talking futuristic, so what do you think is still needed to make it even greater than what we currently have?

Geoffroy Couprie: So, an issue we have when a language compiles to WebAssembly is that a lot of the languages and libraries in the languages have some assumptions about the system under it. Like, oh, I have a POSIX-like network API, or even I have network, I have files. Reconciling that between Windows and Mac, and Linux, or even web or desktop, is pretty hard to do. And with WebAssembly, it’s an entirely new platform where you need to provide some of that. And so even if you can compile the code, just raw code that is not doing any side effects on the network or files to WebAssembly, that can work. But then, once you start using standard libraries that anybody in that language would use, suddenly you can get where, oh, but I cannot just write to a file there, and that’s blocking me from using this pretty well-known library.

That’s one of the main issues, and that’s what they are trying to fix with stuff like WASI, which is a specification for an interface between the WebAssembly application and the host to provide common APIs like that.

Olimpiu Pop: To just see if I got it correctly, what you said is that currently, in the end we still have to run on some kind of machine, and currently there are multiple types of interfaces to just break it down into three different categories, like Web, Linux and Windows probably. You need to harmonise these interfaces so it’s easier to just go from one platform to another. Would that sum it up?

Geoffroy Couprie: It’s more than WebAssembly is another platform. A lot of languages only support Windows, Mac, and Linux, but they now have to support WebAssembly. And it’s not just about compiling. It’s about ensuring that many libraries can effectively utilise WASI, including all their standard libraries.

Laurent Doguin: ‘Cause the main issue is still that you have to convince people that WASM is a good platform to build stuff. And we come from a time where you had to manipulate bytes directly, you had some shared memory, you took those bytes and then you tried to figure out what to do with those bytes. They can be a float, they could represent a string, you don’t know what it is. And so this has been standardised very recently, the WASM component model, and it sort of gives you a common understanding of how to serialise data across and function calls across WebAssembly binaries. So that’s a good step towards adoption. People are working on this.

And then, of course there’s the WebAssembly System Interface, WASI, which is standardising how you would use host functions, which is what Geoffroy was referring to, making sure that we have a standard interface that can be implemented by everyone.

Olimpiu Pop: Okay. Just to make sure that it’s clear for our listeners, we have WebAssembly that pretty much provides, let’s call it, the container, even though it’s more than that. And then we have the WASI, which is the WebAssembly System Interface that provides a mechanism for WebAssembly to safely call different parts of the hardware of the whole system. Am I correct?

Laurent Doguin: Yes.

Olimpiu Pop: Okay, great. Where is WASI after this point? Last time, when they were at 0.1, they were looking at 0.2. Did they evolve from that point on? I didn’t follow it lately.

Laurent Doguin: I haven’t been following that much either. What’s interesting is that the WebAssembly standards are made by the Bytecode Alliance. And the Bytecode Alliance has very different key players in it, and most of them are clouds actually. Most of them are selling hardware.

And you did mention something we haven’t answered yet, which was about pricing. When we did the function as a service at Clever Cloud and pricing, it was really, really hard to price because, while frankly it’s incredibly cheap it’s not of much interest as a cloud platform to sell something that cheap. And I don’t know if there’s a reason, but the Bytecode Alliance have been relatively slow, and Amazon’s in the Bytecode Alliance and a bunch of clouds are in the Bytecode Alliance. And yes, it should drive costs down quite a bit for everyone. So, is this why it’s going slow? I don’t know. It’s just an observation.

Cheaper and greener infrastructure [19:15]

Olimpiu Pop: Yes, well, it’s a tendency towards frugality after a long period during which everybody was just adding cloud services and adding and adding. Now it’s in the reverse trend, but I think it’s a fair point to add that if things were just cheaper, we could probably churn some of the profits, right?

Laurent Doguin: Yes. Cheaper and greener as well because, of course fewer machines.

Olimpiu Pop: Yes. This kind of gets hand in hand, and I think that’s one of the interesting benefits of the Green Tech movement, where it’s cheaper too on the CO2 side, but also on the pocket in terms of finance.

Okay. So the Bytecode Alliance is the one calling the shots, but is there somebody who has more weight in that? As you said, AWS is part of it. Who are the other big players in the Bytecode Alliance?

Geoffroy Couprie: One of the biggest was initially Mozilla, but Mozilla is getting smaller right now. And there’s been a lot of help from Microsoft, from Amazon, and Fastly. Fastly went deep into WebAssembly early. Fermyon, Futurewei. There are a lot of actors.

Laurent Doguin: Intel, Shopify, StackBlitz. It’s interesting because they all have various interests. Some will be very, very, at the bottom of the stack, would be about providing infrastructure, and some will be at the top of the stack, like Shopify, just providing plugins to their infrastructures, or StackBlitz, things like this. And NGINX as well.

Olimpiu Pop: Yes, it’s quite an interesting. I was just scrolling through the list of companies that are part of the Bytecode Alliance, and it’s a broad group, pretty much as you said.

Laurent Doguin: And it has very different interests.

Olimpiu Pop: Exactly. So if you look at it, it’s very heterogeneous. You have Amazon arm and then you have Stellar, the blockchain, cryptocurrency, but also Mozilla and NGINX—so interesting, a sum of people.

Excellent. Thank you guys. The last question from me. Is WebAssembly a silver bullet If you look at it, it started from the browser. Now we are talking about infrastructure. But also, I spoke to people who were just trying to put a box in a box, meaning that they were trying to put WebAssembly in the JVM. So what do you think? Is it a silver bullet? Where are its limits?

Laurent Doguin: The JVM analogy is interesting because the JVM has the same fate as WebAssembly. It started to be something specific and ended up being something completely different. It ended up going away from the initial use case. Now you can use it on the server, but also you had the applets, you had embedded Java, you had all sorts of things that were not necessarily the way it was first conceived. And I think WebAssembly is following the same trend, and people say Java is that, but Java is still alive. So that probably means that WASM has a promising future ahead of it. Is it a silver bullet? Yes, probably.

Olimpiu Pop: Yes. I think so, too.

Laurent Doguin: I’ve been at WASM IO in March with 150 people who were all excited about the future of WASM, and it was probably all convinced that it is a silver bullet, it’s going to be the future. So personally, I’m very excited about it.

Olimpiu Pop: Good point. Thank you.

Geoffroy Couprie: Yes, you cannot do everything in WASM, and it’s still a pretty limited platform, but the limit is what makes it valuable. You want to write your entire application in WebAssembly? Maybe that’s not the right call. If you want a huge microservice to run, consider writing it in your language and using a container. But if you have a small thing that you don’t trust particularly or that you want some kind of behaviour, some little piece of code to go from one place to another in your infrastructure, WebAssembly is a pretty good fit for that.

You can have a tiny piece of code. You know that it doesn’t require many host settings, and you can pre-define those. And you can run that in about any kind of process, and it will not disturb, whether you have Java, Ruby, or C++. You can have your WebAssembly runtime in the same process, and it will run the code pretty isolated. So that’s a good fit for a very small isolated task.

Laurent Doguin: It’s interesting because you say that because it’s not as mature in terms of ecosystem, so you might want to use your usual ecosystem, but will there be a day when it’s going to be as mature so that it becomes counterproductive? Because you also said the value of this is not very big, because the ecosystem is very small. It’s precise. It’s secured. So the more open it becomes, the less valuable it becomes?

Geoffroy Couprie: Yes, but at this point we’ll have another new technology that will come up and that will replace WebAssembly

Laurent Doguin: Fair.

Olimpiu Pop: Okay. Thank you for your time. Anything else to add on your side, guys?

Laurent Doguin: No, it was great to be here and I’m hoping people will get interested in WASM.

Olimpiu Pop: Well, there is plenty of interest, so let’s keep you going.

Laurent Doguin: Geoffroy, anything on your side?

Geoffroy Couprie: Nothing from me. Thank you. I was happy to chat.

Laurent Doguin: Thank you as well.

Mentioned: