Rust, WebAssembly, and the future of Serverless (DevFest 2019)

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
[MUSIC PLAYING] STEVE KLABNIK: Hi, everybody. I'm Steve. Thank you so much for having me. It's been really cool. This is my first time at this conference and in Toulouse. So, OK. This talk, this title, might seem like a pile of buzz words, but I swear it's coherent. We'll get there, eventually. I got the idea-- and it is if I can, like, click the thing right. What is going on? Oh, no. All right. I'm using the presenter view, which I don't often use. I'm trying to use it more. Anyway, the point is, I got the idea for this talk when I saw this tweet. I think this tweet is very fascinating. It's by Solomon Hykes. And he said, if Wasm and WASI existed in 2008, we wouldn't have needed to create Docker. If you don't know who Solomon is, he made Docker. That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task. And this is a retweet of Lin Clark announcing WASI. We'll talk more about what WASI is, later. But I find this tweet fascinating because there's two kinds of people-- people who saw this tweet and went, oh, yeah, that makes perfect sense. And people who saw this tweet and were like, wait, what does Wasm have to do with Docker? Like, this is just completely, totally nonsense. And so, in some sense, this talk is like a 30 minute version of this tweet. Luckily, tweets cannot be half an hour long. I think they used to call those blogs. But, anyway, this is kind of the subject of this talk, and some interesting stuff about Rust and WebAssembly, and where it's going, and all those kind of things. All right. So part one, we're going to talk about Rust. If you weren't at Alexi's talk earlier, you know, I'm assuming maybe you might have heard of Rust by now. But Rust is this programming language that I've worked on for the last couple of years, along with a whole pile of other people. And the current language we're using to describe it is, a programming language that's empowering everyone to build reliable and efficient software. Hilariously, I noticed recently that this is almost the same tag line that Go uses. The Go and the Rust teams are actually very friendly with each other. And unlike people on the internet, we don't, like, argue about which one is better. So it's kind of funny that it's, like, almost word for word. So I think we might need to change it because we don't want to steal their thunder. But, anyway, the point is that Rust is a language that lets you go very fast. If you need speed and you need to do it correctly, that's kind of like where Rust exists. And so sort of how rust came about was, there was this idea for a very long time in programming languages that there was this trade-off between speed and safety. And a lot of stuff in our discipline is trade-offs. And sort of your job is to pick which thing do I actually sort of need? And so a version of this that does not use Sonic kind of looks like this. You sort of had two options. You had C++ which is extremely fast, but not very safe at all. And then you have Ruby, which is very safe, but is definitely not fast. I actually have a Ruby tattoo. I'm not, like, talking trash on Ruby, but it's just not-- it's not fast. It's just not why Ruby was made. And so you kind of had these two options-- do you want to be fast-- live fast and die young? Or do you want to not cause terrible security vulnerabilities? Like, which one? Good job. And so, as part of that, Microsoft released these figures recently. And I will note that a lot of people who saw this chart misunderstood it. This is a chart of all of Microsoft's products and all their security vulnerabilities. And the big blue section on the bottom is vulnerabilities that were related to something called memory safety, which basically means you used a pointer wrong and now you're owned. The other vulnerabilities on the top are every other category-- like everything that's not related to memory safety. And so this line is hovering at 70% because, it turns out, from 2006 to 2018, roughly every year about 70% of the vulnerabilities across all of Microsoft products were related to memory safety. Now, a lot of people said, like, this means that C is terrible or something. But notice this is not actually categorized by programming language. It's categorized by what caused the problem in and of itself. So you can get these kind of vulnerabilities in languages other than C and C++, but usually that's what they're generally associated with. So the idea of Rust is, what if you could be safe, as well? The text on here, if you can't read it, says, I'll be your designated driver tonight. And someone off on the sides says, we know. Don't talk while you're eating or you could choke and die-- ha-ha. Rust kind of gives you this armor that lets you do things in a much safer way. This is from a really great webcomic. I have links to all of the media that I'm using at the end of the talk. But there are a bunch of these for a bunch of other languages. So if you go look up your favorite language, they're all very well done, and it's super amusing. But sort of this idea is, what if we could have the same protections that we have in high-level languages, but you do super low level things at the same time? And could we eliminate that trade-off off? Obviously, there's trade-offs in many directions, not just speed and safety. And so in Rust, you get speed and safety, but you lose some compile time and it's not as easy to program in as other languages. So everything is always a trade-off. Rust is not perfect or the be-all end-all of programming languages. There may be a Rust++ someday. We'll see. Who knows? But the point is to improve the status quo as it exists. You know, it's not the end of programming language history. And one of the things that makes Rust work this way and makes Rust a lot different from other programming languages that you may be using is this thing called a runtime. Now, every non-assembly language has a runtime, including C and C++. But people often say no runtime to mean a tiny one and a runtime to mean a big one because words are hard, and we can't just actually say what things mean. So we have to invent all these terms. And so this is a completely super scientific diagram of a program and how big the runtimes are in them. The light gray is like your code, and the dark gray is the runtime. So Rust has a really tiny one, maybe a JavaScript with the V8 engine. It's not the V8 engine's logo. That's the V8 juice logo. V8 devs either love or hate when you make that joke. I choose to listen to the ones that love it. But, anyway, like V8 and all the other stuff that makes JavaScript work is part of your program when you're running a JavaScript program. And so this will become more relevant a little bit later in the talk. You'll see this slide again. But the only actual bit of Rust code that I have in this presentation-- because this is largely this sort of big overview of things. As I said earlier, the trade-off is, things get harder to actually program in. But it's actually pretty cool, in some ways. Maybe this is just like Stockholm syndrome-- like, you know, you grow to enjoy the thing that beats you up. But it's sort of like working with a pair programmer. Like, you write some code and the Rust compiler is like, uh-uh. You made a mistake here, and here, and here, and here. But, luckily, computers never get tired, and they never make mistakes-- sort of-- and they're there to check your work. So once you get a little better at Rust and you learn to work with this kind of development instead of against it, it becomes much more fun. So when you start out, you're like, oh my god. It's yelling at me all the time. This is terrible. And now, I just kind of like crap out some code and then the compiler tells me where I got all the things wrong, and then I fix it, and it's way easier. So there's sort of this weird part at the start where it feels like a lot of mental overhead and work, but when you get better at it, it becomes easier, which is a very strange feeling. So example what's wrong with this code-- there's this function, add_one, and it takes a mutable reference to an integer, and it adds one to it. Not very super fancy-- it does what it says on the tin. And then in the main function, we create a variable called y, but we don't give it any sort of value. And then we try to pass that to add_one. So the problem here is that we don't know what's in y. So anything can happen. This is what's often called undefined behavior. And, specifically, we're accessing uninitialized memory, which is a memory safety issue. And so the Rust compiler will give you this error and it'll say, hey, you're trying to borrow some uninitialized variable. It says possibly here because it's a little humble. Like, even though it can see it's definitely not initialized, it's like, maybe that's not initialized. I don't know. And then it's like, you're using it on this line, and it shows you where the thing actually is. So, yeah. So you get these kind of error messages. This is the only-- this is a pretty small one that was going to fit on the slide so it's readable. But you'll actually get really in-depth messages where it will be like, hey, you tried to use this thing here. You also tried to do this other thing over here, and this third thing over here, and that doesn't work. And it'll actually take your code and point to all the bits of it. And, like-- there's some people who've put in a lot of work to make these really, really good and useful, and so they generally are. Which is funny because once you get used to them being good it makes the bad ones feel even worse. Like, you're like, come on, most of the time this helps me and now this one doesn't. If you use a language where the error messages are all terrible, you're just kind of like, yeah, whatever. I can't understand this error. That's normal. But when you make like most of them good, the bad ones suddenly become this terrible situation. Anyway, we have people who are just working on error messages and making them understandable, and it's pretty great. So that's Rust. Next up, we're going to talk a little bit about WebAssembly. So the web has been very ambitious the whole time that it's existed. It turns out that, initially, we had just plain old HTML with a little bit of JavaScript. And then, pretty soon, CSS came along, then we started adding images. Like, there's this sort of-- like, a lot of people say that the web has been moving really fast in the last five or 10 years, but it's been moving fast, basically, since it existed, and sometimes too fast, and in the wrong direction, and in, like, five directions all at once. But that's because we're web developers, and we love the web, and we want it to grow and be able to use it in even more and more different places. And so, at first, it was good for just documents and hyperlinks. And don't get me wrong, I love me some documents and hyperlinks. But eventually, people realized that JavaScript is a real programming language and you could write real programs in it, and, all of a sudden, this became way more serious. And we started building everything in web browsers because a web browser is basically an operating system, but that's a whole separate talk, and I don't have time to get into that. But we want to build these really ambitious web applications that can do all sorts of interesting stuff. And so I used to work at Mozilla, and some of my former colleagues there came up with this thing called asm.js. Who's heard of asm.js before? Cool. So, basically, as it says on the tin, here, an extraordinary optimizable low-level subset of JavaScript. The idea here was, we saw this rise of languages and other stuff that would compile to JavaScript. So a great early example is CoffeeScript. You'd write CoffeeScript, it would spit out some JavaScript, and the JavaScript would be what it would actually run because the only thing we had in the browser was JavaScript. And if you wanted to use a different language, compiling the JavaScript is basically the only way to do it. But as people started to build more and more monstrosities of compile to JavaScript shenanigans, people started to think, like, hey, maybe we could make this a little better somehow. And so asm.js is this subset. It's still JavaScript, but it's got some tricks up its sleeve. And it makes it a great way to compile stuff to JavaScript. Here's what I mean. This is some asm.js code-- compiled calculation-- doesn't really matter. It calls a function f and then logically orders it with 0. And then it calls it with g, and does it again. And then it returns the same thing, also like ord. And you're like, why is this happening? If you're familiar with Boolean logic-- which maybe you're not-- doing this with zero-- something or zero is always just something. So this should be a no-op. So why are we doing this? Well, the comments kind of give it away a little bit, here. The trick is that JavaScript doesn't have integers that you can define as a person, but it does have integers in the semantics of the spec. And so when you or something with zero, it's a no-op in number terms, but you get an integer instead of a floating point number. And integers are very fast and very accurate, and floating point numbers are kind of a little slow and they have some accuracy issues. Let's put it that way. And so calculations love integers, so we want to get an integer. So this is like a way to trick the JavaScript engine into using integers when doing your computation. And so this code will run a lot faster than this code, even though, semantically, they mean the same thing. So asm.js was basically, like, can we define a bunch of JavaScript that does all these tricks that you could compile to? Because you, as a human, don't want to write all those or zeros, although some people did. We should make a compiler do that instead. And so this was the idea. If you're interested in the technical details, here's an example from the ECMAscript about why this works. So this is the runtime semantics that are required by the language definition for implementing any of the Boolean operators, not just like the or and stuff. So any A @ B, where the @ is one of the bit-wise operators, so it's like does these things. So the left-hand side is the result of evaluating A. And then we evaluate B. And then we call ToInt32 on the left and ToInt32 on the right, and then the result is a 32-bit integer. So even though you can't write integers in JavaScript, it does have integers, sort of, if you, like, write bad code, which is really interesting. But you can do really cool stuff with this. This is a screenshot of a video. I will not play the video because it's actually removed from YouTube sort of, or whatever. I don't remember and also playing videos in presentations is always complicated. So this is a screenshot. And I remember this coming out, actually. This is like the Unreal Engine running in a web browser at the time. These graphics-- this is a little blurry from some expression artifacts, but this level of graphics the time was mind blowing. Like, whoa, I got this 3D graphics running on my browser? And if you saw the earlier talk about WebAssembly, we talked a little bit about-- well, it wasn't about WebAssembly. It was about web GPU. But we've gone a lot farther than this in terms of graphics in the browser. Like, 3D graphics it's kind of like old hat now. But for a while, it was super, super impressive. So this is actually-- the Unreal folks worked with Mozilla to port the Unreal Engine to asm.js and would compile it to JavaScript. And so this is actually, technically, all JavaScript code running in your browser to do this just, which is really cool. But we started looking at these giant piles of building on top of this weird subset of JavaScript, and it had some holes because it isn't the best thing to do, but it is like a thing, and it is pretty cool. So the folks behind all this decided, hey, we can do something better. Let's just actually build a real thing that's designed for this purpose, instead of hacking yet another layer on top of JavaScript. And so this is how WebAssembly was born. WebAssembly is, basically, all the dreams of asm.js, but done in a reasonable way that people might do if they designed a thing instead of just taking an existing system and turning it until it breaks. Here is why Wasm matters-- well, one of the reasons why Wasm matters. So this is an example of asm.js code, on the top. You can see there's actually this string use asm. That was intended to be a thing that asm.js would do. And the idea was that web execution engines would look for that special string. Because that's also like a no-op, right? You're creating a string and not assigning it anything. So they'd look for the special string and then be like, whoa, I'm in asm.js I should switch into super fast asm mode. And so Firefox did all this work to detect asm.js and compile it specially. The Chrome folks went, like, asm.js is still just JavaScript. Why don't we just make JavaScript faster? And so they actually never even looked for this. They just like made all of JavaScript faster, instead. And so it was sort of a silly idea, but, like, whatever. It happens. So here's the Fibonacci function written in basic JavaScript using asm. So you can see, we take n and we or it with zero. Same thing in the recursive fib calls-- we have all these extra or zeros and we return it. And so you'll see, up at the top there, it says 185 bytes. So this is like 185 bytes of code. If you were to send this over web browser, obviously, you would want to totally run this through Babel and whatever else, and minify it, and obscure all the things, or whatever. But naively written, it's like 185 bytes. On the bottom is a bunch of unprintable shenanigans that doesn't work because it's binary code. And that is actually the Wasm version of this compiled. So it is 62 bytes. You can see, hilariously, it actually starts with the letters asm. That's actually built into the magic number for the binary format for Wasm puts asm at the start of it. So that's kind of fun. But, anyway, the point is that the same thing is actually much smaller, in general. And also, because it's smaller and because it's more regular, it's designed to be parsed real easily. So part of the problem with this, like, we compile-- we learned what the JavaScript does and we make it faster, is you still have to be able to parse the full JavaScript language, even though we're not using the full JavaScript language anymore. And so that's-- turns out it's slow. It's much easier to actually take a binary file that's intended to be executed as byte code and then just like run it than it is to turn a language that was written for humans into byte code and then turn that into whatever. So it's smaller in size so it downloads faster, and it's got all these special tricks to make compiling it into something really fast, really nice. And so that's the way that WebAssembly really improves on this. And so, basically, all of the web browsers now, except for original IE-- somehow, even though Microsoft is doing great things with IE these days, old IE is still like haunting us like around the corner. It's like, oh, I gotcha. Old IE, like non-Edge IE doesn't support WebAssembly, but, basically, every other browser does. So it depends on if you care about them or not. Maybe in 15 years we can stop-- maybe. So, yeah. So that support is in all the browsers now and they know how to execute WebAssembly sort of natively. And so this means we now have options for all sorts of things to compile to Wasm and then use them inside of your browser. The way this works in like a compiler-ish sort of way-- so you wouldn't want to write that binary code by hand, unless you're into that sort of thing. You probably want to write a regular programming language and compile it into WebAssembly. So this is an image made by Lin Clark at Mozilla who makes these great cartoons for explaining topics. Her blog posts are awesome. This is one of her blog posts, and this is the image from it. Basically, you take a language like C, or C++, or Rust, and you compile it into this thing called IR, which is intermediate representation. In this case, it's LVM. It doesn't matter at the moment. And you turn that into WebAssembly, and then your browser takes that and it turns it into native code on whichever platform you're using. As I mentioned before, everything but IE works at this point, basically. And that's pretty cool. So this has been true for about a year and a half now. So all the browser vendors are still working on making WebAssembly super fast and performing. There's lots of-- like, you'll test something one week and it'll be slow. And you'll test it the next week and will be, like, three times faster. And you're like, I guess I updated Chrome in the meantime. But people have been really, really working on this a lot, and it's been really neat to see it evolve. However, I've been talking a lot about Wasm in the browser, but that's not actually what this talk is sort of about. See, the people who work on WebAssembly often joke that WebAssembly is neither web nor assembly, actually. Like, it's not an assembly language, it's a binary format. And it turns out that, increasingly, people are interested in using it outside of the web browser context, even though that was what it was made for. When I think about this, I go back to this talk. This talk is Gary Bernhardt in 2014. It's called The Life and Death of JavaScript. Has anyone seen this talk? Yeah. You should go watch it. It's a trip. I was lucky enough to be physically present for this talk, and it, basically, determined the next like six years of my career, in some sense. Gary is a wonderful presenter. The idea is that it's set in 2050, and Gary is giving you a history of what's happened to JavaScript since 2010. And so it's in this alternate universe. He has this thing called Metal, which is basically what WebAssembly is because this was made up before WebAssembly was invented. But he did talks about how once you compile things to a thing that runs in the browser, a browser is a thing you compile. So, like, this is a screenshot of-- if you'll notice, you have Chrome running GIMP inside of it. But, also, Chrome is running inside of Firefox. And, like, OK, you may say, this is kind of a dumb example and it's out there. Well, 2017, another Mozilla ex-colleague of mine, Dan Callahan, compiled DOSBox to Wasm and then ran Netscape Navigator inside of DOSBox, inside of Firefox. So you actually were running, like, old Firefox inside of then current Firefox. Is this a good idea? Probably not. Nobody's like downloading old Netscape Navigator to use it, but the point is that when I say a browser is an OS, it's really actually an OS now, even more so than before. And you can run really arbitrary things inside of it, including other browsers, depending. So now we've talked about Rust and we've talked about Wasm. It's time to talk about Rust and Wasm together. I showed you this code earlier with JavaScript and the Wasm stuff. You'll notice these byte-size things, as I talked about before. There are other languages, other than Rust, that work with WebAssembly. So Rust does work with WebAssembly for a bunch of different reasons. This is a thing called AssemblyScript, which is a subset of TypeScript that compiles to WebAssembly. And so if you've done some TypeScript, this should look relatively familiar to you. This is a slightly different example of a package that turns-- it gives you 64-bit integers in JavaScript by implementing them in WebAssembly, which, again, is kind of silly, but whatever. The point is that you can write this code that looks like this TypeScript, and then compile this to Wasm, and then you-- it works. But if you remember our slide from earlier-- AssemblyScript is a great project, but there's sort of this weird rift happening in WebAssembly where, if you remember back to this thing where languages have almost no runtime versus languages have a big runtime, WebAssembly doesn't give you a runtime at all. So if you're using a language that requires one, like, say, AssemblyScript, you have to compile the runtime to WebAssembly as well and ship it to your end users. So, for example, like Rust-- you can make a binary in WebAssembly that's, like, 151 bytes I think is the smallest one we made-- 200 bytes-- something like that. I tried the new C# Blazor release, which is really awesome in every respect. But it has a megabyte in size off the top by default. Like, HelloWorld is a megabyte. They're working on that, and they're doing a bunch of great work. AssemblyScript actually has options for four different runtimes that give you various things from garbage collection doesn't exist, to bad garbage collection, to fairly good garbage collection, with varying ranges of sizes. But one of the interesting things here that's kind of happening with Wasm is, these languages that have these bigger run times, they're better for full applications because you don't want a runtime all the time. But imagine you have, like, MPM packages implemented in Rust, and because they're MPM packages, you're now depending on 55 Rust Wasm packages. You don't want 55 copies of the runtime involved. And so solving that problem is one of the big things that the Wasm folks are working on right now. But it means that languages like C, C++, and Rust, that have a small runtime, are, like, extra well suited for this Wasm world because the binaries are smaller. And that's cool. So we recognize this kind of thing. And back in February of 2018, we decided to start a working group within Rust to build out WebAssembly support. And there's been a number of different really great projects that have come out of here. You have Wasm-bindgen, which gives you the ability to call into arbitrary JavaScript and browser APIs, and other stuff. You have stuff like Wasm-pack [INAUDIBLE] lets you build NPM packages that are written in Rust and compiled to WebAssembly, and your users don't even need to know that they're secretly using WebAssembly. And all these other tools and we put a lot of work into making the user experience really pleasant. So we've still been pursuing this, ever since 2018, and are, in many ways, at the forefront of a lot of these kind of things. There was a mention earlier, at the talk about web GPU, where there is a Rust implementation of the web GPU speck that compiles to Wasm and you can use it to build your apps on the desktop, and also on the web, and all this kind of cool stuff. And so RUST and WebAssembly are like a thing. Like, we're super into it. So that's cool. But now is onto the last part-- sort of. So we're going to talk about serverless. Before I talk about serverless, I like people like to make this joke it's not a funny joke. You can stop tweeting. Everyone knows serverless still has servers. But it's about what is being done where and in what way. So this is not my image, but it's beautiful. Again, I have a link at the end of the slide. This is a blog post about the history of the cloud. But we went from having data centers where you would buy big iron and put it in a data center somewhere. And then we sort of moved into this infrastructure as a service world, where you got like virtual machines, like a VPS, and so you're able to spin up a virtual machine, and then SSH into it, and then do all sorts of things instead. And that was like a big step forward. And then, eventually, we moved onto platform as a service where, instead of you needing to SSH in a machine, you just kind of said, hey, I have a Rails app. Please deploy it. And then it would get deployed, and then you didn't have to worry about things anymore. Serverless is kind of the latest evolution of these ideas, where instead of you deploying an entire app, you deploy individual functions. And you're able to scale them independently based on-- there's a big sale today, and so everyone is using the log in and send-Steve-money parts of the website, but nobody's using the read-the-blog part of the website. So let's just spin up only the parts that matter and then leave the parts that don't down. And that saves you money, in theory. In the end, all your money is going to Amazon, no matter which one of these that you use. But I think that we sort of missed something. So lots of people talk about this and they're like, OK, physical machine, virtual machine, set of virtual machines, sort of, and then now its functions and not even a virtual machine. But I think we sort of missed a really interesting shift here. And that is around to this question of-- what is the API that your hosting platform offers to you, as a user? And, most of the time, when people think about APIs for the web, they think about like JSON being posted somewhere, but that's not necessarily what I mean. I mean, like, what is the interface by which you give your application to a provider to have them actually host it? Because there's actually a really big and interesting shift that happened between infrastructure as a service and platform as a service that we kind of lost a little something in the shuffle here. And that is this part. So in infrastructure of the service it says the operating system is the unit of scale. That is, the API the VPS gives you is Unix. That is a lot of acronyms in one sentence. Jeez. Maybe this is a buzzword talk, after all. But the point is that you could deploy anything that implements the Unix API, if you will. Like, anything that compiles on Unix, you could put into a virtual machine. But when we got to platform as a service, it's now like you have a Rails app and you just deploy it. And the difference there is, a Rails app is like a subset of Unix-y stuff. There are many more things that run on Unix than run on, for example, Rails. I'm using Rails as an example here because of my next slide, but this is true of any of these hosting services. You need like, now we support Django, now we support Node, and now we support Go, and whatever else. And so they had to offer specialized APIs because the application was now what you would give them. It wasn't like, here's a box. Go crazy. Like, they had to know that you were running a Rails app and how you would deploy it, which meant that now you would have to build specialized ones for each kind of thing you wanted to deploy. And that was much harder to do because of the number of things you needed to do as the provider of the deployment platform, whereas it was just Unix before. So I went onto archive.org and I dug out the Heroku initial web page. This is some choice-- what is this, 2008? Yeah. October of 2008-- this is like the pinnacle of web design. You got the beta tag up there-- the little ribbon, old Amazon Web Services logos, and Ruby, and Rails, and all this kind of stuff. This is great. I love this. But, yeah, Heroku was originally just a Ruby on Rails platform. And that's because they only had the time, as a startup, to implement one particular kind of API. And they picked rails because, at the time, it was like the biggest one. Rails was super hot stuff back then. And so this was this weird problem where all these companies that started in this era had to figure out which languages they were supporting and at what time. And if you were a user of a slightly more obscure language, you'd have to go beg your favorite hosting provider to add support for your language so you could continue using it. And that didn't really work. So there's this company that existed sort of contemporarily a couple of years later, called dotCloud. And their idea was, what if we had all the benefits of the scaling sliders and stuff that Heroku offers, but instead of being a Rails platform, we're like an anything platform. And this is probably one of the companies that succeeded most massively that you probably haven't heard of or forgot even existed. The reason why this is so blurry is that I had to go dig out images because like their web presence is totally gone now. But you may know these guys by this logo-- Docker. DotCloud needed a way to be able to support any kind of thing while not getting into the specifics. And so they built out some technology to do that for their hosting platform. And whenever they finally decided to release it, they decided to give it it's own name and call it Docker. And it turns out that Docker was way more useful than a particular way to host your websites, and so it kind of grew super massively. And then other people recognized, wait, I have a way that I can manage my hardware and not care about the specifics of the kinds of applications I'm running, and that's super useful. And that's how we got this giant thing of Kubernetes to start managing this stuff. And all these stuff around DevOps things started happening because now we have all these tools where we've sort of abstracted-- we've gone back to where before it was like an OS-ish thing as the sort of like unit of scale again, but with all the benefits of being able to arbitrarily scale different sort of things. And so then we had to figure out ways of managing them. And this is when service meshes started happening and all this stuff. And you can make an entire career just out of managing Docker containers, which is pretty neat. And so if you sort of think about the way that this works, you can take your whatever web app you want to write, and whatever thing you want, and you put it into a Docker container. And the person that's selling the servers or the server capacity, they don't have to worry about whatever is in the container. They just like know how to run Docker containers. And so we sort of found ourself in this Docker-ish sort of like ecosystem. Part four-- the future of serverless. So about Docker-- and as I mentioned before, Docker is this, like, container. The reason that Dockers are cool and why containers are cool is, they limit the ability of the thing inside the container to effect the stuff outside of the container. That's why it's called a container. Right? Like, the idea is that you just pack it up, and you ship it off, and not care what's inside it all. What's inside can't come out. Just like a real shipping container, until you hit a storm and stuff breaks. But the idea was that you could know-- because the outside of the container would set the rules for what was allowed to happen inside the container. You could be sure that your customers weren't uploading like break into my credit card database and steal everyone's credit cards dot rb. And it would be safe for the people outside of the container to run the arbitrary stuff inside the container. But you know what other kind of thing runs arbitrary code in a safe way? Web browsers. Like, I made a joke about web browsers being operating systems before, and, obviously, Docker is not an operating system, but actually a better analogy would be that Firefox is Docker, just in a different kind of way. You download and run arbitrary JavaScript code inside of your browser, and you know that it can't break outside of your browser and do a bunch of other shenanigans on your computer. In the same way that your hosting provider can run a Docker container with your arbitrary code inside of it and know that you're not going to break outside the container and do all sorts of other stuff. And browsers have been around a lot longer than Docker has, and they've had to deal with a lot of way worse kinds of attacks, maybe. One of the things that I realized at one point when a lot of stuff was happening with Firefox and security vulnerabilities and stuff-- and I was like, there are governments trying to hack Firefox and Chrome to do spy stuff with nation states. This isn't like I put a little repo up on GitHub and it's open source, please pay attention to me. This is like other governments are sending their best computer hackers to mess up your stuff. It's like a really adversarial environment. And so browsers have gotten very, very good at containerizing JavaScript and making sure that it doesn't do things it's not supposed to do. So that kind of takes me back to this diagram from earlier about how WebAssembly kind of like works. You compile arbitrary programs to WebAssembly and then that runs inside your browser. And so this is kind of what that original tweet was about. Like, if you put all these things together, all these trends that have been happening over the last couple of years, and you, like, squint in the right way, WebAssembly is basically Docker, in a very strange sense, but inside your browser, not on your computer. And once people started realizing that, they started asking themselves, well, why shouldn't it be on your computer? And that's how we got WASI. This is the actual logo for WASI, by the way. Somebody opened an issue on the repo and was like, could you get a better logo? And they close it, being like, sorry, we're trying to do real technical work here. This logo is fine for now. It doesn't actually matter, and closed it. I was like, that seems very fair. So WASI is short for WebAssembly Systems Interface. It's sort of like if you think about WebAssembly only lets you run stuff inside of the container, WASI is sort of like an API that implementations of Wasm can implement that lets you set permissions around what is allowed to break outside of the container. So do you want your program running in WebAssembly to build access THE network? Do you want to let it be able to access the file system? And you can control this on a per WebAssembly module basis. So it's got these capability systems, and that's really cool. And when I think about breaking through containers, This is the image that always pops up in my head. In what way do you want to let it bust out of what's going on? And so WASI has led to this situation where you can write desktop WebAssembly applications where you compile your C code to WebAssembly and then run it natively on the desktop because you could never run C programs natively on your desktop before. But now you have this benefit of the sandbox, where it won't let the stuff break out of your system. So if you would just compile your C natively and it had a big pointer error in it somewhere, maybe that would be able to break into your computer and steal your stuff. But if you compile it into WebAssembly instead and then run that on your computer, it's slightly slower, but it'll just crash whenever that pointer goes wrong, instead of causing catastrophic error. So that's the reason that you may want to do this, is that you gain the sandboxing ability, not exactly for free, but pretty cheaply, and in a way that's been tested inside of web browsers for a really long time. And so that's kind of cool. Last super big buzz word of the day-- I'm almost done, I swear-- edge computing. This is a term that's popping up more and more lately in sort of the web world. And I definitely do not want this talk to be a Cloudflare pitch, even though I work at Cloudflare. This is a thing that we're doing, and I'm trying to explain to you why we're interested in it. Fastly is also doing this kind of stuff. And Cloudflare and Fastly are sort of but not really competitors of each other. And so I'm going to talk about the awesome things that are going on at both of these places because they're doing really cool stuff with Wasm and edge computing stuff. So this is a map of Amazon Web Services and where all the locations are in the world. I think the red ones are planned expansions that don't exist yet. As we all know, us-east-1-- actually, I don't know if you all in Europe use us-east-1 as much as people in the US do, but that's where like everything-- I knew someone that had a thing set up in their Slack channel where if there was a bad thunderstorm in northern Virginia, it would alert them. And they're like, I'm doing cloud monitoring. Because if there's like a bad thunderstorm and it shuts off the Amazon data center, our stuff is going to go down. And I was like, that's a terrible joke-- monitoring the clouds above your clouds. But if you're deploying stuff on AWS, these are the locations in the world that you can put stuff, at least as of two or three weeks ago, whenever I made this slide. And so that's cool, and there's a lot of them. But if you compare this to, say, Fastly's map of places of presence around the world, there is a bunch more. And if you look at Cloudflare's-- I made this a couple weeks ago. This is actually wrong. We've added like five since then. But, like, we've got a lot of them. And so what's interesting about these CDN-ish companies is that they're building this global network of CDN stuff, but they didn't really think about the fact that building a bunch of data centers for CDN purposes is actually not that different than building a bunch of CDNs for EC2-ish purposes. And so everyone sort of in the CDN game realized, like, wait a minute. We have piles of servers everywhere all around the world. What would happen if we let people run code on them, instead of just caching your images or whatever? And so now it's time for an old buzzword. I don't know if everybody-- I know a lot of you are Java programmers, so you're probably more familiar with this than the last audience I talked to about this. But there was this idea with Java that you'd write once, run anywhere. And at the time, in the late '90s, when this was a thing, it was like a real thing where it was like, whoa, I can compile it to the JVM. And then it runs on any platform the JVM is on. And so it's sort of-- this idea is like similar with the CDN thing, but what if run anywhere didn't mean like Windows and Linux, but it meant the whole way around the world? And so WebAssembly is letting people do that. And the reason why is that the edge has a bunch of things. Like, all of these data centers are not as powerful as Amazon's data centers, and so you need to do certain things. And I don't have time to get into that, I just want to say even more about the broad things here. But we can talk about it later if you're curious. But all of the stuff going on in edge compute is WebAssembly focused. So Fastly has this project called Terrarium and Cloudflare has this thing called Workers. And they basically both let you run WebAssembly in the edge, like on the server that is living somewhere around the world. And what's interesting about these things is that they both have significant components of Rust inside of them. So because we invested with Rust into making WebAssembly tooling great, when people need to start building WebAssembly stuff, they're increasingly picking Rust to do it. And so I think in the same way that Go got really big after Docker existed and it's mostly written in Go, and everyone was like, it just makes sense that cloud native tooling is written in the same thing that the Docker is written in. WebAssembly is kind of doing the same thing. So Lucet is Fastly's WebAssembly runtime. And Wrangler is the sort of command line tool that you upload your code and stuff with Cloudflare stuff. And so these are both written in Rust. And there's a whole bunch of other Rust shenanigans. Most of them have much not as cool logos, so I just left these two up here. Logos look great on slides. But, increasingly, we're seeing people that are doing Wasm stuff build it in Rust because they just kind of mutually reinforce each other. And that's really cool because then, as other people start seeing that momentum build, they're also like, oh, WebAssembly and Rust are this, like, cool thing together. So this is sort of the common denominator with a lot of this WebAssembly shenanigans that are going on. And we've seen an increasing number of people want to program in Rust because they get interested in WebAssembly and vise versa. And so that's really cool. I am actually out of time. So I have this very last slide, this sort of a summary of the points of this talk. The first line is Rust loves WebAssembly. Like, WebAssembly stuff in Rust is really cool. And we're working super hard on it. And if you're interested in Wasm, we'd love to have you learn some Rust to help build it's tooling and do all that kind of stuff. The second one is that WebAssembly and serverless computing are kind of like-- they're not totally sure it's a super great fit yet, but it's like an interesting thing that is happening where it turns out that it seems like WebAssembly and serverless are surprisingly and increasingly becoming part of each other's worlds. And that's a thing that I would have not thought of like four years ago when I first started getting involved in the shenanigans. Like, I thought everything-- like WebAssembly was purely in the browser. And now, increasingly, it seems like in the WebAssembly ecosystem, no one cares about the browser. They're talking about desktop applications. And they're talking about serverless stuff, and all this other kind of shenanigans. So that's a really interesting thing to keep an eye on. And then, finally, edge computing is a cool idea. I don't want to talk about it a whole lot, but it's neat. So with that, I'm going to go. Thank you, so much. Here's a bunch of links. Yeah. [APPLAUSE] [MUSIC PLAYING]
Info
Channel: Google Developer Groups
Views: 30,632
Rating: 4.9220781 out of 5
Keywords: type: Conference Talk (Full production);, pr_pr: GDG/DSC, purpose: Educate
Id: -2BO43FvBuA
Channel Id: undefined
Length: 42min 7sec (2527 seconds)
Published: Tue Jan 21 2020
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.