Syrus Akbary is the founder and CEO of Wasmer, the startup behind the open-source web assembly runtime that's doing for WebAssembly what Docker did for LXC. Syrus explains what WebAssembly is, why it matters outside your browser, and how it compares to other virtualization technologies. He shares the pains that motivated him to look into WebAssembly and eventually led him to create a new WebAssembly runtime and a new company around it. We dive deep into WebAssembly as a technology, its portability and performance characteristics, and talk about the importance of prioritizing community and developer experience when building new development platforms.
Show notes and transcript: https://about.sourcegraph.com/podcast/syrus-akbary
Syrus Akbary is the founder and CEO of Wasmer, the startup behind the open-source web assembly runtime that's doing for WebAssembly what Docker did for LXC. Syrus explains what WebAssembly is, why it matters outside your browser, and how it compares to other virtualization technologies. He shares the pains that motivated him to look into WebAssembly and eventually led him to create a new WebAssembly runtime and a new company around it. We dive deep into WebAssembly as a technology, its portability and performance characteristics, and talk about the importance of prioritizing community and developer experience when building new development platforms.
Show notes and transcript: https://about.sourcegraph.com/podcast/syrus-akbary
Beyang: All right, I'm here with Syrus Akbary, founder and CEO of Wasmer, an open-source WebAssembly runtime and startup that lets you run WebAssembly compiled code outside the browser. Syrus, welcome.
Syrus: Thank you very much Beyang, I'm super happy to be here today.
Beyang: Awesome. So, we have a lot of ground to cover today, and there's so much I want to get to with respect to Wasmer and also WebAssembly in general. But, before we get into that, I always like to kick things off by asking people, how did they get into programming originally?
Syrus: Well, so in my case it's a little bit peculiar because I actually created a website when I was 14 years old, that was for watching TVs and listening radios online. At the beginning actually, I just started, I have a personal website, and I added a new section for watching TV and radio online. And then this section got super popular, so I created a special website for that. All this was pre YouTube, in 2006 or 2005. So, I created this new website, got super, super popular in the Spain, actually we got 300k visitors per month. I remember I put Google ads on their website and I was earning more money than my parents, when I was 14 or 15 years old. So, that was an interesting experience.
Beyang: That's awesome. And I take it from there you were just at the forefront of all the things that were happening on the web, and I guess that's how you stumbled into the WebAssembly world?
Syrus: Well, I will say, it was a little bit longer. So, actually I started doing front-end work, front-end or back-end, actually, at the beginning when I created the website, for me, there was no difference between back-end and front-end, everything was web. So, I did study mathematics, after that I went into a startup in Spain, then I jumped into Silicon Valley, and then from there basically fast forward, I created an open-source framework that become popular, it was in Python for using GraphQL. And then from there I sprung then into the WebAssembly world.
Beyang: Got it. Awesome, and can you explain for people who might be a little bit unfamiliar with this world. What is WebAssembly and why does it matter?
Syrus: So, WebAssembly, it's a technology that was invented by the browser vendors in order to be able to execute code at super, super fastest speeds in the browser, but also in a way that was safe. Basically when you access a website, you want to make sure this website doesn't have access to things that it should not have access to, you have more a sandbox environment rather than native programs. So, that's what had gone into integrating WebAssembly.
Beyang: Got it. And unlike what came before it, you don't have to write your code in JavaScript. You can, in theory, write your code in any programming language as long as it compiles down in a WebAssembly.
Syrus: Yes, so the history of WebAssembly, because everything has started with asm.gs which was created by Alon Zakai... And basically what he did was LLVM bit code converted from, basically LLVM bit code into JavaScript. It was simple because seemed to have super basic instructions. So, he created that subset of JavaScript that could be typed and could be basically interpreted by the JavaScript VMs in a much faster way than normal JavaScript. So, he'd written this, with that you were able to basically run almost any program that could be compiled with LLVM, so that means C or c++ program, so the beginning.
Syrus: Which that basically was a great proof of concept and you started getting games, I'm not sure if it was Doom or Quake or something like that just running on the browser, but super flashy, but then at the same time, Google was trying to push other technology called Native Client. And Native Client was a similar approach to the same problem, which was how we can make run any kind of program at a much faster way in a sandboxed way. So, they created the Knuckle subway to approach that, but it was super proprietary. That means they didn't got agreement from other vendors, and the approach from asm.js, the advantage that they have against Knuckle. Knuckle is different for Native Client. The advantage that the asm.js had was, it basically could work even in browsers that didn't explicitly support Knuckle, and the main reason for all this was because it was a subset of JavaScript. So, that means it could run asm.js, could run on Internet Explorer, or in Firefox.
Beyang: Yeah, that makes sense. And both asm.js and Knuckle were both motivated by people just trying to get away from JavaScript, or writing code in other languages that would be more performant than they could ever make JavaScript runtimes. Is that right?
Syrus: Yes, I will say, performance was a big part of that. Basically, it was not easy to run code at the super speeds with JavaScript. I mean, JavaScript VMs are great, but the [inaudible 00:06:56] you have to run code basically to fulfill the standards of JavaScript, just it will mean that it always will have some overhead. So, in general, even with the best case scenario JavaScript will be two or three times slower than native code.
Beyang: Would you say WebAssembly took more inspiration from the asen.js world or from the Knuckle world, or is it kind of a pretty balanced synthesis of those two predecessors?
Syrus: I think it was from both, honestly. I think they, basically, people from the Firefox team because Alon Zakai was recruited by Firefox. At the beginning he was working on asm.js, I think, also as part of the Mozilla in Mozilla, And I think they just got all together saying, "Okay, Knuckle is not good enough because." Because Knuckle under the hood was actually, I think, using the LLVM bit code. So, Knuckle was not portable enough, asm.js was still JavaScript, so it's like you have to do a special tricks to optimize it. I think they just went all together and decided to create something that basically all the browser's could understand. And actually, funny enough, they created that WebAssembly to JavaScript converter, so basically it will still work with all browsers, even on the ones that they don't regularly support WebAssembly.
Beyang: Got it. That's cool. So, I guess fast forward to day, I think almost every major browser has a WebAssembly environment, and you also have Wasmer which is this WebAssembly environment that runs outside of the browser. Can you tell us a little bit about Wasmer and what's the quick elevator pitch for why people should hear about it?
Syrus: So, just first, to understand what we want at Wasmer. I think is good to do very simple analogy, which is, if you remember what no GS did bringing JavaScript to the server-side, we are doing something similar. Taking the WebAssembly technology that was created on the browsers, we are moving it server-side. And the main question is, why you are doing that actually, why people would want to execute WebAssembly server-side? And the main reason for that is, that with WebAssembly you have a universal binary format that almost any chipset or platform could understand.
Syrus: So, that means is fully portable, but at the same time is super sandboxed. So, the fact that this is sandboxed and also is super fast and it's universal, it makes it actually ideal just to run software in general. So, that's one of the realizations that I had. And basically why I started Wasmer was, because when I tried to use WebAssembly server-side, I realized that he was actually very, very hard. And the Go system was [inaudible 00:09:56] to run WebAssembly server-side. So, as someone with that very hardcore developer mindset, I thought actually we could improve that experience and make it much easier for developers, and for companies to startup in WebAssembly server-side, to run software.
Beyang: Cool. What languages are compiled down into WebAssembly at the moment?
Syrus: So, at the moment there is C and c++, of course. We have Rust as well, apart of Rust we have Go. We have other languages that are also likely to compile down to WebAssembly, in general, any language that under the hood, basically, is compiled and is using LLVM under the hood, could be compiling to WebAssembly. But, then there are other projects that are actually made impossible to, for example, convert a Java bytecode, or basically there is a real incentive for languages to be able to target the browser. Why? Because it expands their market.
Syrus: So, that means almost any other language right now is trying to compile down to WebAssembly, because it just like a sponsor market and make sure that the language prospers on the long term. So, on one side we have Java bytecode that could be compiled to WebAssembly with JVM, we have also a Python interpreter, because Python is still like interpreters so you have to compile the interpreter itself to WebAssembly, and then you can run it, which is actually already possible. I would say almost any other language from [inaudible 00:11:34] that you can imagine, it could be compiled down to WebAssembly, either in that full compile form or in the interpreted way.
Beyang: So, the WebAssembly dream is this Holy Grail that people have been after for a while now, which is, "I could write code in any language and I should be able to run it anywhere, whether that's in the browser or on the server, or on my desktop machine running any operating system." The dream is, write it in any language and then run it everywhere, is that right?
Syrus: Yes, that's the ideal scenario. Basically, I think we have been working a lot on trying to run software in different platforms, we realize that it's actually quite hard. We realize that it's quite hard to integrate programs that are made in Rust, integrate them in our Python programs, or programs that are in made in C, how we can integrate these into our JavaScript programs. Or, for example, we create a program that will work in our Mac machine, but the same binary will not work in Windows, or this same binary will not work in Linux.
Syrus: So, we assume a lot of issues that we have when running software, that should not exist. And WebAssembly basically remove all these barriers, and what it allows us is to just make sure that one binary could actually be executed in any platform, or basically in any ecosystem very easily. So, it's, if you realize it's actually quite close to what the promise of the Java virtual machine will be, with a main difference that is it's, I will say, the bytecode format is much better designed, because it have a lot of lessons learned. Also, you have industry... Basically all the industry wants to push for that, and it's an open specification is not proprietary. So, I think this is actually what is pushing WebAssembly even farther.
Beyang: Cool, and I want to rewind a bit to earlier when you were talking about your motivations for creating Wasmer. So, you mentioned that you created Wasmer out of these pain points that you experienced working on your previous startup Graphene. And can you talk about what the WebAssembly ecosystem was back then and what was the gap that you saw that Wasmer is trying to fill?
Syrus: Yes, some background, around four, five years ago I created this GraphQL framework for using GraphQL in Python, called Graphene. And this framework become super, super popular. When I created the company about Graphene I was actually competing against other startups that have funding, where actually Graphene we didn't raise any money. I had no idea how to raise money, that's been a nice learning, but I had no idea how to raise money so we didn't have money on the bank, and I was trying to see how I can expand the Graphene ecosystem.
Syrus: And I realized that if we actually target WebAssembly, we could get Graphene actually used in a lot of different languages. Why is that? The graphical is spaces is very special, and this is special because there is a reference implementation which is made in JavaScript, and all the other implementations that you see in Python, in Ruby, in rust, basically in Go. They are all porting by hand the JavaScript reference implementation to the different languages, and a night on this and it's been super time consuming. And I realized why we need to do that, why I have a program and they need to translate it from JavaScript into Python, this it this is suboptimal.
Syrus: So, ideally what I realized we could have is actually one universal Engine that could run everywhere. Could run in Python, could run in Go, could run in Rust, could run in Java, and that means you don't need to recreate a lot of the integration issues, or the integration things with a certain program language that you have, basically you can assure that will be given by the universal library. So, that's what it pushed me to start researching, at least, into the WebAssembly world.
Beyang: Got it, that makes sense.
Syrus: And that's why what got me into WebAssembly. But then, the more I dig into WebAssembly the more I realize that it could be useful, not only for using universal libraries that could be using a lot of different programming languages at the same time, but also for cloud computing and edge computing, and IoT.
Beyang: Got it. And were there existing WASM runtimes, back then, that ran outside the browser or was Wasmer the first?
Syrus: No, there were others, there was WAVM. WAVM was one of the first WebAssembly virtual machines that existed. And, actually, I collaborated a lot into WAVM before starting Wasmer, I mean, when I say a lot it's just like three or four pull requests, so not really that much more. It was made in C, and I'm not super familiar with C, but actually it was not easy for me to collaborate into, although actually [inaudible 00:16:56] was great, he was awesome. But, I realized WAVM was also taking a lot of time to compile an idea like that, and then I collaborate in to what the runtime called Wasmjit, which right now doesn't exist.
Syrus: This one was actually creating by hand all the assembly code, that was where it was corresponding to certain WebAssembly operation, and I realized that path was actually very suboptimal, it was very, very, very hard to maintain. So, with these two approaches I realized that there was... Basically, the system solutions that were standalone were not easy to run WebAssembly server-side, were not ideal for me as a developer to use it. And then I started sneaking into the Vms that the browsers use, because all their browsers have the WebAssembly VM that is tightly integrated into their JavaScript VM.
Syrus: So, that was great, that was very insightful, but I realize that running a WebAssembly VM within their source code without JavaScript was actually quite, quite challenging. So, that's when I realized that actually we need that engine that it's decoupled from the JavaScript engine. And, again, browsers do optimizations that are in general useful to remove the boundaries between JavaScript, or to increase the performance when you cross boundaries between JavaScript and WebAssembly. But, in the case of there is no JavaScript, actually, the kind of phrases that you want to make are a little bit different, so that's when I decided that we needed a proper runtime to run WebAssembly server-side.
Beyang: Got it. So, you tried some of the existing WebAssembly runtimes on the server-side, you had various difficulties, some difficulty collaborating in existing code-based, you checked out the in- browser runtimes and it was hard to just rip those out, so that motivated the formation of Wasmer?
Syrus: Yeah, and at the same time he was funny, because at the same time I saw an article from CloudFlare where they were basically talking about CloudFlare workers and isolates, and they were mentioning how fast the startup times, basically how fast they were compared to normal Containers. And at that moment, basically, my mind did click and it was like, "Okay, this is going to be big, this for run software in general and the ecosystem is still very early. So, there is a big opportunity to actually provide something to help developers and to help companies [inaudible 00:19:38] WebAssembly server-side.
Beyang: Yeah, that makes sense. Yeah, I've heard a lot about CloudFlare investing in WebAssembly as a runtime to run serverless workloads. Are they building their own runtime or are they using Wasmer, or how they go about doing that?
Syrus: In the case of CloudFlare they are using V8, because actually their CloudFlare workers offering is highly tied to JavaScript. So, you can actually do JavaScript on their VM, so for that reason they are actually using V8. There are some issues when running, actually, WebAssembly on V8, which is, when you want to speed up compilation time and when you want to cache it, and so on, there's this deserialization time, which is the operation that you do to skip compilation and just basically getting it from cache. The deserialization time is much lower than if you actually have native images. So, in general, V8 have trade offs that are, I will say, not as good for running WebAssembly server-side. Although, it's actually it's a super great WebAssembly runtime.
Beyang: Got it. And are other cloud computing companies also investing in this or is CloudFlare the only one?
Syrus: So, CloudFlare, I'm not sure if it was the first one, or on the CDN space, or if it was Fastly. So, Fastly also has been down researching on the WebAssembly, on the server-side world for some years, and they actually like open-source Lucet about which is our WebAssembly runtime. The open-source is about four months or five months after we open-source or we created Wasmer, and the main reason for that was because Wasmer was actually given all the attention, and they were working on this WebAssembly VM for years. And they were like, "Fuck, there is some strange person or company now creating the runtime, and as we have everything, basically we are getting none of the community gains from that." So, the open-source Lucet, and I think Lucet did a lot of good decisions on the way of running WebAssembly server-side. And actually, funnily enough, for Wasmer 1.0, we are getting back a lot of the learnings of the Lucet fast. But, Lucet is also a great runtime created by great people.
Beyang: Yeah, That's great. It sounds you force their hand a little bit, and in encouraged them indirectly to release their technologies open-source as well.
Syrus: Yeah, it's funny, we go like this... The Politics of open-source are a little bit weird, and that means sometimes when you're on the open-sources space and you have like, let's say, competing products. You always have to fight to win that battle against basically who's going to get the users. But in general, I will say, the ones that benefit most from this are actually the users, because when there is more ways of running WebAssembly server-side, basically they have more choices, and with more choices they can choose whatever is best for them. And that means the ecosystem just evolves at a faster pace. So, I think it was a very good moment for a move from the Fastly team to open-source it.
Beyang: Yeah, I read a lot of internet comment threads where people talk about the WASM wars or things like that, it sounds like things are really heating up in the space, so it was pretty exciting.
Syrus: Yeah, it's funny, because the WASM wars have been real. I wouldn't have never imagined that, I felt the wars we're going to be in some other space. And the other thing is, at the end, it's less about wars and more about what we can provide for the users, in our case, we are 300% focus on how we can improve the experience of users using WebAssembly server-side. And in the case of Lucet, actually, I will say their main goal is being able to supercharge their CDN. So, that means the available experience might not be as polished because their focus is somewhere else, which is fine. Basically, there are different trade offs in each of these approaches.
Beyang: Totally. It seems to me, from what I've observed, that Wasmer from the get go has really made developer experience and community building a priority for the company, and also the open-source project. Can you talk a little bit about those efforts around building the community and what the community looks like today?
Syrus: So, when I started Wasmer I realized that this ecosystem or this market was going to get field by a lot of different big companies, that wanted to basically be part of the space. And when you are an underdog that's quite challenging, it's like how we as a company, we are going to be able to survive when Google tries to do something on this space, or how we are going to be able to survive when a billion dollar company like Fastly does something in this space, how we are going to be able to get users? And at the end I realized community was a very big part of that. So, if you build more or if you focus more on that, then it's going to be easier for you to have a good spot on the long term.
Beyang: Yeah, I think one of the efforts that might be related to this, I'm not sure maybe you can clarify, but the fact that WAPM, or W-A-P-M, the WASM package manager, that's another project that came out of Wasmer, right?
Syrus: Yes, funny story. I actually created, or built WAPM one year before I created Wasmer. And the main reason for that is, I felt WebAssembly was going to become big, and they were like, "Okay, there is no package manager." The package manager is quite important actually to be able to distribute software. So, there was no package manager, I created the logo first of WAPM, and actually if you analyze or if you compare the logo of WAPM and Wasmer. Wasmer is lyses of the WAPM box, and this is super intentional. But, the main reason for that is because actually I created the WAPM logo first, but WAPM is this package manager for distributing software created for WebAssembly.
Syrus: Basically it's a package manager, it is fully designed for the WebAssembly ecosystem, because sometimes I get the question of, "Okay, why people will use WAPM and will not use NPM?" And the main reason, I will tell them, is when you ask basically Python developers if for running Python programs actually they have to install NPM, almost all of them will reject that idea, and the same for Go. But, when you have actually a package manager that is not trying to push you towards any ecosystem, because WebAssembly's all the ecosystems, it's all the languages at the same time.
Syrus: So we don't want that table Python, or Rust, or Go, over C. We don't want to do that. Basically, we just want to be one very easy way to distribute this server that can be used across different languages. So, that means we are not biased against JavaScript, and that means all of the developers will... When they try to, or when they want to use these universal software, they know that we are not trying to push JavaScript in their Python environments, for example. So, it's a much proper way or a much easier way to get them basically using the ecosystem.
Beyang: Yeah. Can you talk more about the developer experience of using a package, a WAPM package that's written in a different language? Because, for me, most of the package managers I've used have been tied to one particular source language, so I'm coding in Go, I want to take a dependency on something, it has to be a library written in Go. And that library doesn't exist yet, I have the port something else written in another language to Go, which is always super annoying. What does it look if I'm writing Python and I want to use some other library that might be written in Rust?
Syrus: So, right now there is a standard interface for running WebAssembly, this is called WASI. And this interface is similar to POSIX, which means [inaudible 00:28:22] to able to open files within a sandbox environment, but open files and re-directories and things like that. So, that means if you have a Rust program right now, and you want to use this Rust program from Python. It could be a CC as basically compiling your Rust program into WebAssembly with the WASI target, and then once the program is compiled you just execute it directly on the Wasmer Python runtime.
Syrus: And the cool thing about that is Wasmer, even though it's actually made in Rust, we have integrations with a lot of different languages. Basically it allows you to use a WebAssembly VM, not only in Rust or not only in JavaScript, but also in Python or in Go, or in Swift, or in Java, or in C#, or basically wherever you want to use it. So, that means, first you compile your WebAssembly or your program into WebAssembly, you have a micro Container, let's say like my program, WASM, and then from Python you just execute it. And, right now, we are working on making super, super easy this intercommunication between the Python program and the Rust program, but there is some work going on that is not valid yet, like the interface types.
Beyang: Got it. So, in the end state it would be something like, you have this mini executable that gets distributed and probably some lightweight wrapper in each source language that wraps that mini executable, so that if I'm using Python I can still Pip install that wrapper package and then import it in my Python code, just like any other Python package. Is that the experience that you're going for?
Syrus: Ideally, that will be the end ideal experience. So, that means, "let's go back to our the original use case that I imagined for Wasmer," which was these universal GraphQL library. So, these universal GraphQL library could be made in any language that actually can be compiled directly into WebAssembly, which could be Go, could be Rust, could be C or c++. So, we first compiled this GraphQL library into WebAssembly, and then we basically create the bindings or create a internet layer that let us create the bindings for all the different language integrations, basically at One Click.
Syrus: So, that means you just say, "Okay, these are the different functions that you can call from other languages, that are exposed in my library." And then from different languages you will have these functions are exposed, and then you just will interact or intercommunicate with this library quite easily. So, at the end you will have one library made in whatever language, compiling to WebAssembly, and then you will reuse that library in any other language as if it was a native library for that language. So, you don't need to worry about converting types or anything that.
Beyang: Got it, that's super cool. It's maybe roughly analogous to how, in the JVM, if I'm writing Java code, I can use a library that's written in Closure, or Kotlin, or something else that compiles down to JVM bytecode.
Syrus: Yes, t's funny that you mentioned the JVM, there is actually one initiative that is coming from Oracle called GraalVM, and it's super interesting. Basically, you know that Java has been always slow to startup, because you have to warm up and basically it's a little bit slower to startup. And that's fine because their long term performance is super awesome, but the main thing is, right now, basically Oracle's investing a lot of time to be able to pre-compile these jars into native code. They did that for basically the Java language with a framework called Truffle, and then they expanded this framework to be only not using Java but also to understand other languages.
Syrus: So, funnily enough, GraalVM actually, right now, lets you use Python to intercommunicate very easily Python with JavaScript, and with Ruby, and with C, and within LLVM, it's crazy. But, the main thing about GraalVM is, it's basically like you are tied to Oracle, it's basically you're always having the same problem as you were having before with the JVM, which is normally what you want is something that this is standard pushed by all the industry and not by only one player.
Beyang: Yeah, that makes sense. So, the selling point of WASM and Wasmer over that is, I get all the portability of the JVM but faster startup times, and also I can use non JVM languages as well.
Syrus: Yeah, and basically you can use whatever you want. One of the things that I think, it was hard for the JVM to basically conquer the whole world, it was a lot adoption on the language side. Basically, if you were using Python in Java, you can not use the [crosstalk 00:33:50]. And that means, you will have some compatibility issues, hopefully not, but there probably will be some especially if you're a big company. So, that issue of not being able to use already existing ecosystems, I think was a deterring factor for the adoption of the JVM.
Beyang: Yeah. Now, why is it that the JVM ran into those adoption issues among other languages, but WASM isn't going to run into those same issues. Is it some design choice in the runtime or...
Syrus: So, it's more about the choices of the people working on these companies did, what they wanted is to keep people, almost everyone on their ecosystem. So, when you want to basically capture people and don't let them out, what you do is you encourage them to use proprietary things rather than things that already. Why? Because you have more control over them. But, this on the long term is actually resulting to the negative, at the end what is always good is using or reusing things that already exist. So, that means that JVM at the beginning, they did something to understand basically LLVM and Bitcode, for example, that could have been a very, very big win for them, but they didn't have the incentives to do it because they wanted to capture and keep people within their ecosystem, not going somewhere else.
Beyang: Got it. So, it's like Oracle owns the JVM runtimes, or at least the ones that are popularly in use in most companies, and so they want to preserve control over that, Whereas, WebAssembly it started its life as this open standard, and there's many different implementations of that standard right now, so you don't have to worry about lock-in as much.
Syrus: Yeah, it's not just lock-in, basically you can reuse software that already exist. You can reuse the Python in WebAssembly, which is awesome, you don't need to create that Python for WebAssembly explicit. And that's a very big win because that means you will get the same kind of errors, the same issues, the same thing that you get in the normal Python. So, you don't need to spend time worrying about, "Okay why this in this environment is behaving this very weird way, when actually I was expecting this other thing?" So, use the same software.
Beyang: As someone who had to run some Jython code back in the day, I can vouch for the pain, that extra layer of... Well, it's not indirection it's just the realization that what you're running is not actually Python it's something different, and so if you Google for error messages or you try to debug something, you can't really reuse any of the existing corpus of information. Okay, cool. Yeah, that makes sense. So, we've talked a bit about Wasmer and WASM as compared to the JVM, I think another comp that people make is to another technology which is Docker, or more generally LXC and Containers. Can you talk about the comparisons and contrasts between WebAssembly and what Containers allow you to do, because with Containers they also had this early selling point of, write any language, run in any environment, it's portable, it's lightweight, et cetera, et cetera.
Syrus: Yes, so it's funny that you say that, because actually the Containers are not really that much portable. So, I mean, when you create a Container that works in your X86 machine, which is normally the chipset that you have in your laptop. These Container will not work natively in that era machine, that means the Containers are chipset dependent, but not only that, both Docker Containers and LXC Containers depend on having a Linux operating system under here. So, even if you're running Docker on Mac, you're actually, Docker in Mac is running a Linux VM, is under this Linux VM where you learn where you run the Containers.
Syrus: And the same for LXC. LXC actually have a kernel integration, you need a Linux kernel integration and you cannot, for example, run LXC in Windows or a Mac. So, this is one of the first realizations, but I will say the main would be one is, we have to Containers, the ones that are used until now, that are the operating system-based Containers. Basically you scale things thinking on machines, basically how many machines, how many VMs I'm going to have running this code.
Syrus: You think of that because, actually, there is a entity called the operating system that actually lives in each of these machines. In the case of Wasmer or WebAssembly, you're going to have operating system-based containers, what you have is application-based containers. And when you remove all the overhead that, actually, you require for running operating system, then you end up with a much lighter Container. It's much lighter in two ways. One, is because the Containers are actually much more lightweight, they're basically smaller in size. On the other part that actually it's a very good selling point for WebAssembly.
Syrus: It's that the startup times are actually quite quick compared to Docker Containers or LXC. And the main reason for that is, when you have a Container that it's a operating system-based Container, when you start up that actually you have to run a lot of things from the operating system just to start. And these in the best of the cases, really on the best of the cases, when for example you use Firecracker, which is very fast runtime for Containers created by Amazon. In the best of the case you can get 150 milliseconds off a startup time. When you remove all this overhead, then you can end up with much smaller Containers, and also you can get the Containers that can have a much faster startup speed.
Syrus: So, that means WAVM is starting this Container at 150 milliseconds, the Container will start in 50 nanoseconds. And this, when you're running a lot of Containers actually matters, but I will say it mainly matters because there are new trends that are coming, that we all can think or believe are going to become important, like serverless. And right now we are trying to basically shape serverless, trying to adapt into a structure actually [inaudible 00:40:32] that match the match.
Syrus: So, the main reason for that is, right now, even in serverless you can use operating system-based Containers like Docker, but the main issue there is, because the startup time is at least 150 milliseconds, you cannot start up with a Container per HTTP request, for example, if you want. You actually need to use [inaudible 00:40:56], the cold approach and the hot approach. That means what happens if a Container get requests very frequently and what happens if not. And this is not optimal, but with WebAssembly you can actually startup a Container per request. Doesn't have almost any overhead, and that I think is a very big win.
Syrus: And they have to end, for me the last important thing that I think is going to become very relevant, especially on the next year, is the Moodle platform side. Right now, if you want to run Docker on Windows, or if you want to run Docker on Mac, you need to have a Linux VM unloader kit, which basically that's overhead. I'd say for LXC, basically LXC is you need kernel integration, and not just that, so that means they're not only chipset dependent but are also platform dependent. In the case of WebAssembly, you can have one Container that will work exactly the same way in Windows, that will work exactly the same way on Mac or on Linux, and at the same time it will work exactly the same way in Linux X86. Basically in your normal tips that you have on servers, and it will work in ARM. And family fact, why this is important. We all know that, for example, right now Apple is moving into ARM, into the apple cycle.
Syrus: So, right now we know there are tons of developers that are using Apple laptops actually to develop. What do you think will happen when these developers, actually, will try to use Docker Containers on their Mac? They will see the performance decreased by four to five, and that's very bad because, actually, their experience will be much, much worse. And the main reason is because actually what they will be doing is emulating an X86 machine into their ARM chipset.
Syrus: So, I mean, basically they're emulating, this is not going to be fast. In our case we pre-compile it, we compile this WebAssembly code into whatever chipset and platform you're using. So, that means you don't need to worry about just running a faster speed, because you will always run cold on process that's been available in your chipset.
Beyang: Yeah, that's a that's actually an angle I hadn't even thought of before. If companies Apple are moving to ARM you're going to have this bifurcation of ARM and X86.
Syrus: Yeah, and even before, even we don't look at that. Even if we look at what software is created for Linux that cannot run in Mac, or software that is created in one Linux distribution, but cannot run in the other Linux distribution, which actually is very lame but it happens. So, we remove all these things, we can have actually a universal store that will give us binaries that will work everywhere.
Beyang: Yeah, that's actually one of the big selling points of Go, which is a programming language I use quite often, just the ease of cross compilation to different platforms. But, the issue with that is that it works as long as you're using Go, but as soon as you want to use another language you obviously can't use the Go compiler to create portability for non Go language.
Syrus: Yeah, but-
Beyang: Okay, so you've talked... Sorry, go ahead.
Syrus: No, I was going to say that in the case of GO, you can actually create binaries for a lot of platforms, or in the case of LLVM is also quite similar. But, the main difference there is actually, you have to maintain, you have to distribute all these different binaries for all these different platforms that you want to support. Ideally, you just distribute one binary and forget.
Beyang: Yeah, that's fair. So, you've talked about portability, you've talked about startup time, but surely there must be a trade off here because you're introducing a another layer of indirection, which is the WebAssembly runtime, Wasmer in this case. What about the performance in the warm state? Presumably it's no faster than running natively, so what performance hit are we talking about here?
Syrus: So, in general, basically what we are doing is what Web-Assembly VMs are doing, are compiling these WebAssembly code to machine code. The thing is, in general, when you have this level of abstraction, there is always some overhead. In the case of Wasmer we have multiple compilers, and in our basically server-side recommended tier, we are using LLVM. So, the cool thing about that is we can reach almost native speeds, the overhead is around five to 10% slower, but there is one catch here, which is actually sometimes it's even faster.
Syrus: So, we have one person that he was basically benchmarking bcp and tar compression, and [inaudible 00:45:54] compression, and it was comparing the native ones versus the WebAssembly ones. And basically this person, so our head of... And one test was 6%, in other was 8%, in other it was 9%, and in other was -30%. That means Wasmer was 30% faster than Native. And you will ask why the fuck the habits? And the main reason is- [crosstalk 00:46:23].
Beyang: [crosstalk 00:46:23].
Syrus: No, it is because WebAssembly started beat, actually the pointers are smaller, and when the pointers is smaller you can do some opening of the [inaudible 00:46:33] on the cheap side that you cannot do on the 64bit machines. So, it means that sometimes you can even end with faster, perhaps.
Beyang: Wow, that's crazy. Another topic that comes up in discussions I've seen about WebAssembly was Docker is the security topic, and there's been a lot of discussion around Docker security in general. I've been privy to a lot of these discussions about Docker defaults to running as root, and it's actually quite easy to break out of the sandbox if you know what you're doing. Can you talk a talk about how WebAssembly and Wasmer compares to that?
Syrus: Yeah, in one side I will say that, actually, LXC solves that very elegantly. So, you don't actually need to run LXC into, or you're going to run LXC Containers in a unprivileged way. But, in the case of Docker, basically Docker just release everything to operating system, that means the bindings between the Docker Container and the operating system are minimum, are basically just transparent.
Syrus: And that means, when you don't do any effort to sandbox it as a middleman, then these things can happen. In the case of LXC they do actually things more smartly when overlaying system calls to the operating system. So, that means they can assure that the system calls you want to do, we have the right to do that.
Syrus: So, this is in the case of Docker versus LXC, but in the case of Docker versus Wasmer, the main difference is actually in the WebAssembly world. When you run WebAssembly programs or WebAssembly modules, you actually have to be explicit about what kind of functions this program can access. So, that means, but that by default a WebAssembly program cannot have any interaction with the host, basically cannot call any function in the house. So, that means, by default, if you want to open a file, open socket or, I don't know, do something dangerous. Whatever you're trying to do will not be exposed, and if you want to be exposed, if you want to expose that function, then you have to be explicit about it. So. that's the first layer.
Syrus: The other part is, Web Assembly by default is secure, and it's secure because it separates what is the executable code from the data. And why is this important? Sometimes in C you can actually compile code that given a raw pointer, that means a raw direction of data, will be able to call that function, will basically be able to call a direction of memory as if it was a function. In the WebAssembly that's impossible. In the case of WebAssembly, if you want to call a function you have to follow the function call, either a call or call indirect. But, you cannot call into an explicit part of the memory, that is basically just data not executable.
Syrus: So, on one side you have executable memory, which is where you put the functions, and the other side you have data memory, that is where you put the data, and both are completely separate. So, given the data memory, you cannot try to call a function there, because WebAssembly will or, and that's something that you can do in the C world or in the Native world that anomaly. So, that's another big distinction that you can... Basically you're more protected on the WebAssembly space.
Beyang: Yeah, that's pretty interesting. Yeah, I just saw this tweet that I saw a while back, it was from Solomon Hykes, the founder of Docker. He said something to the effect of, "If WebAssembly had existed and it was as mature as it is now when Docker was created, there would have been no reason to create Docker."
Syrus: Create Docker.
Beyang: Are you familiar with that tweet?
Syrus: Yes, that's funny because, actually, when I started Wasmer we got one small investment, and then this investor introduced us to someone. And since January I was basically talking with Solomon and trying to see if, basically, he could invest in Wasmer. It took him some months to realize, basically, the power behind WebAssembly. And then, almost at the same time that he tweeted, "Oh, if WebAssembly existed when I created Docker I will not create the Docker, basically, I would've upgraded something different."
Syrus: And that isn't at this moment, actually, he also decided to invest in the company, which was obviously good, because then, again, basically when you're creating a startup and when you're trying to raise money. Basically having validation from someone that have created some something that that became big, that's a good validation point. So, that was very, very good for us.
Beyang: Yeah, I want to dig into that more. From your perspective, do you think that Wasmer will supplant Docker or LXC is the go to, shall we say, virtualization technology or deployment technology for most server-side workloads in the next five to 10 years or so?
Syrus: I believe so. That's that's why I'm betting very, very big on Wasmer. I think having a universal platform or a universal format that basically any computer, any chipset, any platform can understand. The advantage of that are super, super big. So, I believe basically that's going to be the way that we are going to run software in the future. Why? Because if sandbox by default this multi-platform is universal and is fast. So, when you put all these things together you're like, "Okay, why would you not use that?"
Beyang: Do you think there will be a Kubernetes for the WASM ecosystem, or do you think Kubernetes will just extend itself to accommodate WASM-based Containers, or what are your thoughts on that?
Syrus: I have very peculiar thoughts, first, because where the future of Wasmer as the company actually goes more on the infrastructure side of WebAssembly.
Beyang: I see.
Syrus: I will say, that the same way that Docker enabled Kubernetes, that means Kubernetes before Docker didn't make sense. And Docker created a new set of needs that were not necessary when you were basically orchestrating software before. I think the same way that Docker enable Kubernetes, Wasmer will enable other thing.
Beyang: Got it, that's super interesting. It's almost like, I look at what The Cloud, Compute players, the AWSs, and Azures, and CloudFlares of the world are doing. And it's almost like with Kubernetes this layer of abstraction got introduced that prevented them from building their own cloud operating systems, if that makes sense. So, with Kubernetes there's still some level of stickiness, but it as long as you're running on Kubernetes it's, in theory, you can switch between cloud providers. And it's almost like in the serverless mode, that's their attempt to leapfrog Kubernetes and build more platform dependent computing API's that bypass Kubernetes, I wonder if they are all trying to prevent a Kubernetes-like thing from emerging in the WASM ecosystem. It's just me thinking out loud there.
Syrus: Yeah, it's funny, we got all these things when you have ecosystems that already exist, usefully, and you have new emerging technologies that were not existent when they first technologies were created. So, that means WebAssembly [inaudible 00:54:36] when Kubernetes was created. So, what then doing is, you're then trying to adapt to Kubernetes to able to run WebAssembly which, for example, Microsoft is trying to do right now.
Syrus: I personally think that the way that you should scale WebAssembly software is quite different than the way that your scalable operating system Containers is quite different than the way that you scale application-based Containers. So, even though, actually, you will do these right now, because transitions are important, and you want to make sure right now you're going to use WebAssembly on your Kubernetes workloads. I don't think that's the optimal thing to do on the long term.
Beyang: Yeah, it makes sense. Can you talk about what themes and areas the Wasmer team is going to be focusing on in the next 6, 12 months?
Syrus: So, what we are trying to do is, we want to empower the community. We want to make sure everyone that wants to use WebAssembly server-side will be able to do that, and right now it is still quite hard. Even though actually Wasmer provides the best experience, WebAssembly itself as a system is still quite young, so that means if you want to compile from Rust to WebAssembly is... I mean, from Rust WebAssembly, I will say, trivial, but if you want to do it from Go it's not as trivial, or if you want to do it from other languages it's not as easy.
Syrus: So, I think lowering that barrier I'm making super easy for people to use WebAssembly server-side. Basically that's going to be one of our goals of this year, and then on the other side is basically the monetization side. How Wasmer as a company will be able to make money, because we all know Docker itself, even though created a lot of value for a lot of different companies, was not able to capture most of this value. And the main reason is because it's a runtime, and your users are developers. So, in the guess of Wasmer runtime is, we are hardly going to get any money from this. So, we need to start researching into other ways of revenue, and it's fine. Actually, we love to have Wasmer a runtime to be completely open-source and not a paid product, but we need to start researching into what are different ways that we can expand our market and that we can become a... If not profitable, at least like a company that is able to prove that there is some interest on the enterprise side.
Syrus: Basically like on that interest being able to launch tools that makes super easy for these enterprises to adopt WebAssembly server-side. So, that's the things that we want to continue working on, but there is always a part of the community basically giving back, that we are very, very, very big on. I think we need to give back if we want to grow the ecosystem.
Beyang: Yeah, makes total sense. We're almost out of time here, but before we go, I wanted to ask, as a last question, if someone is listening to this and they think Wasmer is super interesting and they want to check it out, try it out, what should they do, where should they go?
Syrus: So, we have a website wasmer.io, that actually in this website they can find links to the GitHub project, they can find links to the rapport, or to the team, basically who's working at Wasmer, they can find links to our blog and basically learn different articles that we publish. Where we compare basically Wasmer versus all runtimes, and where we compare basically what are the different trails that you do when choosing a compiler, and basically our learnings. So, as your ally, I will we recommend people to just go to wasmer.io and sneak there. We also have a Slack community channel that I welcome anyone to join, is slack.wasmer.io.
Syrus: And basically go there, ask questions, we are super open and we always want to help. We have a lot of different companies and small developers using us, and we want to basically make super easy for you to adopt Wasmer, and if he's not Wasmer, even adopting WebAssembly. So, if you join our community or you visit our website, or rapport, or have any questions, just open up a issue in GitHub or just write a message on the Slack, and we'll reply very promptly.
Beyang: Awesome. My guest today has been Syrus Akbary. Syrus, thanks for being on the show.
Syrus: Thank you very much, Beyang, I really enjoyed chatting today.