Why (and How) We Wrote a WebAssembly CMS - Matt Butcher & Radu Matei, Fermyon Technologies

I wanted to ask everyone to do the program committee a favor. Here were me, Sherry Lindsey, and Taylor, all from cncf and divya, who presented the

webassembly

text file presentation today, but the two people who have been constantly working behind the scenes to make Wednesday happen sooner. In Los Angeles again, here are Ralph Scholagi and Liam Randall, so please give them a round of applause. I'm going to ask you a favor, although unfortunately Liam Randall spent the day at an airport and I hope he's watching on the live stream, so if you can, do what you can to direct the applause towards the camera.

Hopefully we'll get a round of applause for Liam. He has worked tirelessly behind the scenes, so just for Liam, please, one more round of applause. Thank you so 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 passed great. Bernard will come after me and after Radu and I and we'll wrap things up. My name is Matt Butcher. I am one of the founders of Fermion. We think we see waves in technology and we think we're about to see the next wave of cloud computing and we think web assembly is really going to play a really crucial role. role in the next wave of cloud computing, so we're really excited to host this to talk about some of the things we've done and thank the community for all the really cool things that are coming out.

I'd like to list a lot of projects I've worked on in the past, but people who know me tend to know me from the illustrated children's guide to Kubernetes that I co-

wrote

with Karen Chu, so if you've done that, if I fall into uh, childish explanations of things, you will totally understand why Radu matai, down there is my co-founder, one of the co-founders of Fermion. He really he is around the computers all the time, but he says that when he is not around the computers. he likes cycling and boba tea and stuff like that, not sure when he's not around computers, although I've also been asked a couple of times if we're going to introduce the fussy mustaches again today, we're not, uh, talking of that.

We'll talk about it again at dockercon earlier at the Hashi Trusted Open Source Summit, but we have something very different to present today. We started fermion in November 2021. We delayed launching our website from then until February and the reason is because we wanted to prove that we could run our website on

webassembly

on the cloud side and that meant building our own content management system and I'm sure you're thinking why you would choose to write your own content management system. Part of the reason is because we are engineers and there is nothing engineers like more than to reimplement something, but really the reason for us was that we looked around the webassembly ecosystem and saw a ton of cool projects that we we had worked on ourselves, a lot of projects, crestlin wagy and bindle and stuff.

So and I personally had contributed probably 20 hello world programs to the webassembly ecosystem, so we decided that we don't want to start with another demo, we want to be able to lead with something that goes beyond a normal demo, maybe something that we could run in production maybe something that we felt would really use a lot of web assembly as it is today and then be able to prove to people that no, this is a technology that is ready for use in production. Now I'm a little inherently impatient, uh. and then you won't hear anything in my talk, well you know we had to wait for networking or we have to wait for this or that type of thing, instead what you will hear is that we looked at the technology and we said we can build.

There are interesting things with this today, we can run it in production and I think we can produce some really interesting results, so although webassembly is perhaps in the early stages of adoption and particularly as it applies to the cloud side , is in the early stages. stages of adoption we wanted to show that we could go a little further than what people assumed they could do with webassembly we were hearing people tell us oh I don't know fermion, you know, don't you think you could be a little bit? too early in the market or you don't think you'd like to wait until maybe networking is complete or maybe threading is complete you can't really create anything useful in wasm yet and I really mean it got under our skin . everything went well, we just want to show that we can really create something fun and cool and something we can run in production, so we built a cms.

Now part of my experience is the work of cms many, many years ago, as Lynn Clark. from fastly, who writes the code, cartoons, we had both worked on drupal many years ago, anyone here who had ever used drupal or on the other hand were wordpress enthusiasts, yes, and I really liked the management system of dynamic content where a lot could be built. of things and where you could build a lot of tools that would run the moment the client requested something instead of a static site generator that spits everything out early so we wanted to build a dynamic cms as part of that again because drupal but another Part of that was because we wanted to be able to upload a lot of content to our blog and time that content to deploy automatically and we didn't want someone to have to press the button in the static window. site generator to be able to load that content on the right day at the right time, so a lot of the inspiration for bartholomew or cms came from drupal, but not all the features, some of them we took on, we continued the tradition of jekyll and hugo and static site generators because we liked the way it was very simple to write content, you could write it in Markdown and put a little header on top and you basically worked in your text editor or your code and that was really comfortable for us, so we borrowed Mark Down as a text format that we borrowed, we used Tommel as a header format and you know, I think we built something that really takes the things that we liked about static site generators and the things that we like dynamic site generators now. once it's dynamic you need ways to extend it properly, you want to be able to do things like dynamically list what 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 use. rye, which is actually a really cool project that's like, I guess, a Rust script, it borrows Rust syntax, it's dynamically typed at least to some extent, it's very easy for us as Rust developers to learn and begin.

Use to do things like list the blog post and make, you know, modifications to where things appeared on the screen, so we used Drive for our scripting language and then we chose a template engine. I was in charge, it's one of my projects and I believe. Honestly, one of the biggest mistakes I made with helm, if not the biggest, was not putting a lot of thought into the templating language I chose. I used ghost template language at the time, no one really used it. I spent a ton of time documenting it, it was very frustrating for a number of people, I think it's still one of the most frustrating features of helm, and as we got closer to it, everything went well.

I'm going to take a very different approach instead of choosing, you know, which one is the smartest in Firsthand, I'm going to find one that people say they like and I'm going to use that instead. Handlebar was very popular in the JavaScript world. It has many people who use it. There are books about it. There are articles. all over the place and I'm fine, well that will work, so we find a handlebars library and use it as a template engine. We also wanted to make sure, as a new company entering a new space, that we had plenty of SEO optimizations. a lot of performance optimizations because one of the important things for us is that if we are going to tell people about webassembly, we need people to find us so they can know how to read about webassembly, so we spent a lot of time from the beginning designing the cms so you know that the source order would be correct, we would use it, we would follow all the best practice specifications, we would have a robots.txt file, we would have a sitemap, we would have an atomic feed and things like that. and we incorporate everything so that, essentially, when an author writes content he does not have to think about SEO beyond going.

I need a good catchy title, so that was a really interesting approach that we had from the beginning and then. Of course the last one, Ronan, our designer who did the slide designs here, the Fermion logo, the website design, is an amazing designer and an amazing html css wizard too and we wanted to give him the freedom to do things as you would like, so we wanted to make the system very easy to theme so you can choose your own theme engine, you can choose your own CSS framework and JavaScript libraries and bring all that in, so this is a very important set of features to use in a system that people say no I don't know, it may not be production ready, but I'm not sure anything can be built, so we really took on this challenge of saying we think we can build something really cool with webassembly, as it stands today, what language do we choose to write it in? well we choose rust, why do we choose rust?

Because we like rust. I mean, honestly, there wasn't much more reason than that we thought, oh, we really like crust. We could have written it in an assembly script. We could have used lowercase. Come on, actually the Fermion site has components written in several different languages, including Grain and Tiny Go, and now with delicate mustaches we also have Ruby there, so we build a bar, we build Bartholomew, the cms in Rust, we just use libraries that we were able to take it off the shelf unmodified, so we didn't have to go into any of these libraries and edit the code or add feature flags or anything like that.

We simply use the ryze scripting engine, just as we use the handlebar template engine, as is. use the tomml parser as is and so on and the only real library we used that wasn't very specific to what we were doing is the spin core library which roddy will show a bit later as we look at some of the code generation and stuff, so we were really trying to prove once again in another dimension, another dimension of all of this, right, that we could build something with web assembly using off-the-shelf components without having to. any fork or something comment stuff or something and create a feature set that is a real content management system, not a toy, not a demo, so Bartholomew was originally written in waggy, which is one of the projects that we did. webassembly gateway interface is basically cgi for web assembly, as we developed our next generation execution context called spin, we changed all this stuff to the spin framework and then as we went to deploy we realized that we could write a file so add a file server in the cms we could add, you know, a redirect library that you know does 307 redirects or things like that or we could write them all as separate web assembly modules and then basically line them up all in the spin configuration and mount them on different pads there and basically treat our web server, our web front end, the fermion.com website as a batch of microservices, so the file server is a favicon fava favicon microservice, depending however you prefer to pronounce it's a microservice, redirection is a microservice, they are all written in different languages ​​so we assemble part of bartholomew cms from small separate projects which are then fully reusable and we end up reusing the file server in all the places where we use it in spin.fermion.dev.

Use it on delicate mustaches and other places too, so from these things we put together a content management system that we launched on February 8th and so far we haven't had any downtime on the web assembly side. We had a case where our load balancer crashed, but it had nothing to do with the web assembly side, so we felt like we proved that we could run web assembly in production with a real workload and so we started testing it . Fortunately, the Internet helped us try it when trends changed. news sites we saw huge amounts of traffic coming in at one point, we had over 2000 simultaneous requests coming in, we were running three instancessmall t2 in ecs because we are a startup and our budget was tight, so you know, kubernetes.

The cluster requires at least large instances before you can start it and we were running it on small instances and watching traffic coming in and out, oh but it held up remarkably well, we never actually saw CPU utilization jump above 70, the memory remained constant at around 40 even when we were under tremendous load and the most exciting thing was that when we ran all this through the Google page speed test, we scored 99 out of 100 and got an average of about 53 milliseconds of response time on a cell s on a round trip, so we were absolutely ecstatic with what we were saying, so I'll hand it over to Radu, who will come and show a demo and talk a little more in depth about some of the technical details of Bartholomew. the cms, how would we greet?

So one of the things we had to build first, the content management system, was Bartholomew, but the second part was actually running it and accepting web requests and then coming back, 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 little template to start a new Bartholomew website so you can use the spin cli uh we have a couple of templates and we'll look at the tiny go example in a couple of seconds, but what you can do is make a new twist of bartholomew and at this point you have the building blocks to create a new website with bartholomew and all you have to do to write a new page is just what what you would expect with a static site generator is to add a new markdown file, what is it, oh that's why yes, and do a spin and at this point, you can navigate to localhost and then spin will automatically redirect your page and what will happen is that Bartholomew will dynamically grab the markdown file, grab the handlebar template that represents our blog, which is just a regular handlebar template, and render it dynamically. the page and display it in your browser, so we've seen how Bartholomew takes his content and markdown templates and renders the page from him, but what we haven't seen yet is what actually happens when he takes an app that's in the content management. system and try to run it and try to compile it on webassembly, so the second thing we want to show is spin, which we've talked about a little bit, we touched on it a little bit, but spin is our open source framework for building microservices with webassembly and running them at scale spin It is based on the webassembly component model which we sincerely believe is the future of webassembly everywhere and we are very excited for it to get more and more traction from developers, but what we really wanted with spin was the experience you would get When writing a normal web driver, regardless of your programming language, everyone is familiar with writing a function that takes an http request and returns an http response and uses all the libraries that you would normally use when handling web requests regardless of the programming language you use. we've seen throughout the day people demoing Rust and people talking about how Rust is absolutely amazing in general and particularly in building web assembly applications, but we're also big fans of tiny go and we'll get to that in a second. how you can get started with your first spinning microservice with tiny go and the same thing, we want to be able to reuse standard library objects, so if you've ever written a go handler function 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 it and spin will return the response to you, add to that a little drop file that defines your component and defines the path. which your component is supposed to handle and every time there is a new request, the slash hello, spin will instantiate the webassembly module which is compiled from your handler function, regardless of the programming language, it will create it, run it the handler function and then it will return the response, so let's see how we can actually start something like this, same as before, we have a couple of templates that we maintain to spin, we have http written in tiny go rust and then the bartholomew one that we just saw , so do spin new http go and at this point spin created all the necessary files for us and again the necessary files are a small spin.omo file which contains the path and a bit of configuration and then your controller function, so which by running this we can do a spin build up and what this will do is run the little go build command it will compile the code into the webassembly module and then it will start of course Bartholomew is still running on the same port so we can do the same thing and then spin will start a web listener and every time we have incoming requests it will respond, we have seen it before and we have seen that the program talks about tiny go and how amazing and how small and how fast it is, but and we have seen.

We talked about webassembly and how it runs Bartholomew and how it runs our website, but let's see how fast it is, so we have a little load test that will start bombarding our website with five current connections for 10 seconds, so hopefully, What will we do? What I see is a bunch of 200 correct results, but what we really want to see is that the response times measured by the client running webassembly modules written in tiny go are on average 153 microseconds and in a span of 10 seconds we managed to handle 300 000 requests in total and for each request, what happens is that we take a web assembly module, instantiate it, call the function defined with the component model with bind gen and then execute the function and return the result, everything It happens within 153 microseconds, as measured by one customer, so we're very excited about the twist and we're excited for people in the community to join in.

We've already seen a lot of external contributors and we're really very grateful for that, but the most important thing is what I think All I want to do is give a big shout out and thank you to the webassembly community. None of the work we've seen here today since 9 a.m. It would have been possible without all the amazing people working on webassembly standards and in webassembly. implementations and I want to especially thank all the people at the bytecode alliance and the web developers and Western Time for all the amazing work they continue to do, so I would really like to give them all a round of applause. awesome people so yeah thank you for giving us the opportunity to come and show our cms also show the spin system we are about to finish the day so bernard will be coming soon to close things up for the day again thank you all of you and enjoy the last talk.