 I wanted to ask everybody to do a favor. Program committee here was myself and Sherry, Lindsay, and Taylor, all from CNCF, and Divya, who presented the WebAssembly text file presentation earlier today. But the two people who have consistently worked behind the scenes to make Wasm Day happen before in LA again here are Ralph Squalace and Liam Randall. So please give them a round of applause. I'm going to ask for a favor, though. Liam Randall has unfortunately spent the day in an airport, and I am hoping that he is watching on the live stream. So if you can, do what you can to direct the applause toward the camera. Hopefully we'll get a round of applause for Liam. He's worked tirelessly behind the scenes. So just for Liam, please, one more round of applause. Thank you very much. I know that means a lot to them. They really have been working for a long time to make this happen. The day has gone great. Bernard will come up after me. After Roddy and I and kind of close things down. My name is Matt Butcher. I'm one of the founders of Fermion. We believe that we kind of see waves in technology, and we believe we're about to see the next wave of cloud computing, and we think that WebAssembly is really going to play a really crucial role in that next wave of cloud computing. So we're really excited to present this to talk about some of the things we've done and to thank the community for all the really cool stuff that's coming out. I would like to list a whole bunch of projects that I've worked on in the past, but people who know me tend to know me from the Illustrated Children's Guide to Kubernetes, which I wrote along with Karen Chu. So if I lapse into child-like explanations of things, you'll totally understand why. Roddy Umatai down there is the co-founder, one of the co-founders of Fermion. He really is around computers all the time, but he does say that when he's not around computers, he enjoys cycling and boba tea and things like that. I'm not sure when he is not around computers, though. Also, I've been asked a couple of times if we are going to present on finicky whiskers again today. We are not. We talked about that at DockerCon earlier. We will talk about it again at Hashi Confident Open Source Summit, but we have something very different to present today. We started Fermion in November of 2021. We delayed launching our website from then until February. And the reason why is because we wanted to demonstrate that we could run our website on Cloud Side Web Assembly. And that meant building our own content management system. And I am sure you are thinking, why in the world would you choose to write your own content management system? Part of the reason for that is because we're engineers, and there's nothing engineers like more than re-implementing something. But really, the reason for us was that we looked around the Web Assembly ecosystem and saw lots and lots of great projects. We ourselves had worked on many, many projects, Crestlet and Waggy and Bindle and stuff like that. And I personally had contributed probably 20 Hello World programs to the Web Assembly ecosystem. And so we decided, all right, we don't want to lead with another demo. We want to be able to lead with something that is beyond a regular demo, maybe something that we could run in production, maybe something that we felt like would really exercise a lot of Web Assembly as it is today, and then be able to demonstrate to people, no, this is a technology that is ready for production use. Now, I'm kind of inherently impatient. And so you won't hear anything in my talk about, well, we needed to wait for networking, or we need to wait for this or that kind of thing. Instead, what you'll hear is we looked at the technology and said, we can build cool stuff with this today. We can run it in production, and I think we can produce some really cool results. So even though Web Assembly is maybe in the early stages of adoption, and particularly as it applies to the cloud side of things, is in the early stages of adoption, we wanted to demonstrate we could go a little beyond what people were assuming that they could do with Web Assembly. We were hearing people saying to us, oh, I don't know, Fermion, don't you think you might be a little too early into the market, or don't you think you'd like to wait until maybe networking is done, or maybe threading is done? You can't really build anything useful in Wasm yet, and we really, I mean, it kind of got under our skin. We went, all right, we just kind of want to prove that we really can build something fun and something cool and something that we could run in production. So we built a CMS. Now, part of my background is in CMS work. Many, many years ago, like Lynn Clark from Fastly, who writes the code cartoons, both of us had worked on Drupal many years ago. Anybody in here who had ever used Drupal or on the flip side were WordPress enthusiasts? Yeah, and I really liked the dynamic content management system, where you could build a lot of stuff, and so where you could build a lot of tools that would get executed at the time the client requested something, as opposed to a static site generator that spits everything out early. So we wanted to build a dynamic CMS. Part of that, again, because Drupal, but another part of that was because we wanted to be able to load up a bunch of content on our blog and time that content so that it just automatically rolled out. And we didn't want to have somebody have to press the button on the static site generator in order to upload that content on the right day at the right time. So a lot of the inspiration for Bartholomew, our CMS, was drawn from Drupal. But not all the features. Some of them we carried on in the tradition of Jekyll and Hugo and the static site generators, because we liked the way that it was very simple to write content. You could write it in Markdown and put a little header at the top. And basically, you were working in your text editor or your code editor. And that was really comfortable for us. And so we borrowed Markdown as the text format. We borrowed UIsToml as the header format. And I think it built something that really takes the things we liked about static site generators and the things we like about dynamic site generators. Now, once it's dynamic, you need ways to extend it. You want to be able to do things like dynamically list which things are available right now or allow people to sort things. So of course, we added a scripting language because we all need another scripting language. We used Rai, which is actually a really cool project out there that is sort of like, I guess, it's Rust script. Sort of. It borrows the syntax of Rust. It's dynamically typed at least to a degree. Very easy for us as Rust developers to pick up and start using to do things like listing out the blog posts and doing modifications of where things showed up on the screen. So we used Rai for our scripting language. Then we chose a template engine. I was, Helm is one of my projects, and I think, honestly, one of the bigger mistakes I made with Helm, if not the biggest, was not thinking hard about the template language that I picked. I used Go's template language. At the time, nobody was really using it. I spent lots and lots of time documenting it. It was very frustrating to a number of people. I think it still is one of the more frustrating features of Helm. And so as we approach this, I went, all right, I'm going to take a very different approach. Instead of going with what's the most ready-at-hand one, I'm going to go find one that people say they like, and I'm going to use that one instead. Handlebars was very popular in the JavaScript world. It has lots and lots of people who use it. There are books about it. There are articles all over the place. And I'm like, OK, well, that will work. So we found a Handlebars library and used that as a template engine. We also wanted to make sure, as a new company entering a new space, that we had a lot of SEO optimizations, a lot of performance optimizations. Because one of the important things to us is if we're going to tell people about WebAssembly, we need people to find us so that they can read about WebAssembly. And so we spent a lot of time up front designing the CMS so that the ordering of the source would be correct. We would follow all the specifications for best practices. We would have a robots.txt. We would have a sitemap. We would have an atom feed and stuff like that. And we built it all in so that essentially when an author is writing a piece of content, they don't have to think SEO beyond going, I need a good catchy title. So that was a really interesting focus that we had early on. And then, of course, the last one, Ronan, our designer, who did the slide designs here, the Fermion logo, the website design. He's an amazing designer, an amazing HTML, CSS wizard as well. And we wanted to give him the freedom to do things the way he wanted. So we wanted to make the system very equally themeable so he could pick his own theme engine. He could pick his own CSS framework and JavaScript libraries and bring all of that. So this is a very hefty batch of features to be using in a system that people are saying, I don't know, might not be production ready yet. I'm not sure you can build anything with it. So we really took on this challenge of saying, we think we can build something really cool with WebAssembly as it is today. What language did we choose to write it in? Well, we chose Rust. Why did we choose Rust? Because we like Rust. I mean, there honestly wasn't much more of a reason than that. We were like, oh, we like Rust. We could have written it in an assembly script. We could have used tiny go. We actually, the Fermion site does have components written in a number of different languages, including grain and tiny go. And now with finicky whiskers, we have Ruby in there as well. So we built Bartholomew, the CMS, in Rust, used only libraries that we could pull off the shelf unmodified. So we didn't have to go into any of these libraries and edit out code or add feature flags or anything like that. We just used the Rye scripting engine as is. We used the handlebars template engine as is. We used the Tommel parser as is, and so on and so on. And the only real library that we used that wasn't, that was very specific to what we were doing is the SpinCore library that Roddy will show a little bit later as we look at some of the code generation and stuff. So really, we were trying to just prove once again in another dimension, another of the dimensions on this whole thing, that we could build something with WebAssembly using off-the-shelf components without having to do any forks or anything like that, comment things out or anything like that, and build a feature set that is a real content management system, not a toy, not a demo. So Bartholomew was originally written on Waggy, which is one of the projects we did. Waggy is WebAssembly gateway interface. It's basically a CGI for WebAssembly. As we developed our next gen execution context called Spin, we switched all these things over to the Spin framework. And then as we went to deploy, we realized we could add a file server into the CMS. We could add in a redirecting library that does 307 redirects or things like that. Or we could write all of those as separate WebAssembly modules and then just basically line them all up in the Spin configuration and mount them to different pads on there. And basically, to treat our web server, our web front end, the fermion.com website as a batch of microservices. So the file server is a microservice, the favicon, favicon, depending on how you prefer pronouncing that, that's a microservice, redirecting is a microservice. They're all written in different languages. And so we assembled part of the Bartholomew CMS out of little separate projects that then are totally reusable. And we ended up reusing the file server all over the place to use it on spin.fermion.dev. We use it on finicky whiskers and other places as well. So from these things, we assembled a content management system. We launched on February 8th. And thus far, we have not had any downtime on the WebAssembly side. We had one case where our load balancer tipped over but had nothing to do with any of the WebAssembly side. So we feel like we demonstrated that we could run WebAssembly in production with a real workload. And so we started testing it. Fortunately, the internet helped us test it. When things trended on different news sites, we saw huge amounts of traffic come in. At one point, we had somewhere upwards of 2,000 concurrent requests coming in. We were running on three T2 small instances on ECS, because we're a startup and our budget was tight. And so Kubernetes cluster takes at least large instances before you can even start it. And we were running it on small instances and watching the traffic come in and go, oh, but it held up, held up remarkably well. We actually never saw CPU utilization jump above 70%. Memory stayed constant at about 40%, even when we were under tremendous load. And the most exciting thing was when we ran all of this through the Google PageSpeed test, we scored a 99 out of 100. And we were averaging about 53 milliseconds for response time over SSL and around-trips. So we were just absolutely ecstatic over what we were saying. So I'm going to hand it off to Radu, who's going to come up, show a demo of it and talk a little more in-depth about some of the technical details of Bartholomew, the CMS. So one of the things that we had to build, first of all, the content management system was Bartholomew. But the second part was actually running it and accepting web requests and then returning. So right now you can try Bartholomew using Spin, which is our open-source framework for building microservices on top of WebAssembly. And we have a tiny template for starting up a new Bartholomew website. So we can use the Spin CLI. We have a couple of templates. And we'll see a tiny Go example in a couple of seconds. But what you can do is do a Spin new Bartholomew. And at this point, you have the building blocks for creating a new website with Bartholomew. And all you have to do to write a new page is just what you would expect with a static site generator, which is add a new markdown file and do a Spin up. And at this point, you can navigate to local host and then Spin will automatically redirect your page. And what will happen is Bartholomew will dynamically take the markdown file. It will take the handlebar template that renders our blog, which is just a regular handlebar template, and it will dynamically render the page and display it in your browser. So we've seen how Bartholomew takes your markdown content and templates and renders your page. But the thing that we haven't seen yet is what actually happens when you take an application that is in the content management system and try to run it and try to compile it to WebAssembly. So the second thing that we want to show is Spin, which we've touched a little bit on. But Spin is our open source framework for building microservices with WebAssembly and running them at scale. Spin is built on the WebAssembly component model, which we wholeheartedly believe to be the future of WebAssembly everywhere, and we're really, really excited about it getting more and more traction from developers. But what we really, really wanted with Spin was the experience that you would get from writing a regular web handler. Regardless of your programming language, everyone is familiar with writing a function that takes an HTTP request and renders an HTTP response. And using all the libraries, you would normally use when handling web requests, regardless of the programming language. So we've seen throughout the day people demoing Rust, and people talking about Rust is absolutely amazing in general, and particularly at building WebAssembly applications. But we're also really, really big fans of Sinego. And we'll see in a second how you can just start it with your first Spin microservice with Sinego. And the same thing, right? We want to be able to reuse the standard library objects. So if you've ever written a go handle handler funk to handle web requests, this is literally just using the net HTTP package. So you're writing a function that takes an HTTP response writer and the request, and you can manipulate that, and Spin will return a response for you. Add to that a tiny Tommel file that defines your component and defines the route that your component is supposed to handle. And whenever there's a new request coming on slash hello, Spin will instantiate the WebAssembly module that is compiled from your handler function, regardless of the programming language. It will instantiate it, it will execute the handler function, and then return the response. So let's see how we can really start something like that. So same as before, we have a couple of templates that we maintain for Spin. We have an HTTP written in tiny go, Rust, and then the Bartholomew one that we just saw. So we do Spin new HTTP dash go. At this point, Spin created all of the necessary files for us. And again, the necessary files are a tiny Spin Tommel file that contains the route and a bit of configuration, and then your handler function. So running this, we can do a Spin build up. And what this will do is it will execute the tiny go build command. It will compile the code to WebAssembly module, and then it will start, of course, Bartholomew is still running on the same port. We can do the same thing. And then Spin will start a WebListener, and whenever it will have incoming requests, it will respond. We've seen earlier, and we've seen dead program talk about tiny go, and how awesome, and how small, and how fast it is. And we've seen us talk about WebAssembly, and how it runs Bartholomew, and how it runs our website. But I would actually see how fast it is. So we have a small low test that will start bombarding our website with five concurrent connections for 10 seconds. So hopefully what we'll see is a bunch of 200 OK results. But the thing that we really want to look at is the response times. As measured by the client, executing WebAssembly modules written in tiny go is, on average, 153 microseconds. And in a span of 10 seconds, we managed to handle 300,000 requests, and for each request, what happens is we take a WebAssembly module, we instantiate it, we call the function defined with the component model with Byngen, and then execute the function and return the result, all happening within 153 microseconds as measured by a client. So we're really excited about Spin and excited about people from the community joining. We've already seen a lot of external contributors, and we're really, really thankful for that. But more importantly, what I think we all want to do is give a big shout out and thank you to the WebAssembly community. None of the work that we have seen here today from 9 a.m. would have been possible without all the amazing people working on the WebAssembly standards and the WebAssembly implementations. And I want to give a particular shout out to all the people in the Byte Code Alliance and the Wezzentime developers for all the amazing work that they keep putting out. So I would really like to give a round of applause to all the amazing people. So yeah, thanks for giving us an opportunity to come up and show our CMS, also show the Spin system. We're about to wind down the day, so Bernard will be coming up shortly to kind of close things off for the day. Again, thank you all and enjoy the last talk.