 Welcome to this webinar on the next evolution of WebAssembly, the component model. My name is Sohan Maheshwar and I'm a lead developer advocate at Fermion. So, I'm going to start off with maybe some, with a statement that could be a little controversial, which is, it's really time to reboot software development. And the way we have been building and architecting software all this while has been based on certain assumptions. And now with the next evolution of WebAssembly, these assumptions will change. So, really it is time for us to reboot software development. Let me give you an example. And this example is called the 2400 hour problem. Now, basically parsing a URL or a URI is, while it is a non-trivial task, it is fairly simple. You have a URL like this that looks like HTTPS colon slash slash www.farmion.com slash blog. And this has a protocol. It has a host and it has a path name. And sometimes it could have some queries after it as well. Parsing this is straightforward, right? And every single programming language out there has its own or multiple URL parsers that are standards as libraries that are used. Now, here's the thing. C++ has one, Java has one, JavaScript has one, Rust has one, if not many. And it estimates, rather we have estimated that it's taken at least 2400 person hours to actually construct all of these parsers from scratch. Each language needs its own, each framework needs its own. Why couldn't we just use a single parser that was created as a specification? Well, the problem is there are so many different languages out there and each of them need their own parsers. Apply the same thing for other specifications, cryptographic keys, all of these computing things that really have specifications but need to be implemented from time to time in every language and framework there is. Well, all of this is going to change with something called the component model. So really in the future if you're building a JavaScript app, you can say something like I need a YAML parser and you can actually grab a YAML parser that is written in Rust because Rust is good at doing things like parsing since it is a low-level language. Similarly, you can say like I need a date format and you can use a Python library because Python is good with numbers to really do that and all of this in your JavaScript app. How this is going to work? Well, that's what I'm here to tell you. To understand how the component model works in WebAssembly, you need to know a bit about WebAssembly and the boring answer about what WebAssembly is is it is another portable bytecode format which means that it can run anywhere as long as there is a runtime for it. Now, this was originally developed for the web in the mid-2010s and it was meant to be lightweight, portable, security sandboxed by default. And here's the thing, all of these things are good for a browser but they're really great for the server side and to be serverless. Now, for anything to run on a server, you need access to things like files, clocks, system interfaces, random number generators and so on. And this didn't exist up until 2018-19 when something called WASI was introduced. This stands for WebAssembly Systems Interface and this essentially allows you to run WebAssembly outside a browser. So you don't need a browser anymore to do all of the cool things WebAssembly is capable for. It gives you access to files, file systems, clocks and random numbers, completely independent of a browser or a runtime that is on the browser and it extends WASM security sandbox to include input-output. So for a WASM file to work with another file, you have to explicitly give it permissions to get access to that file because it is security sandboxed by default. How essentially WASM works very simplified is you write code in any language, right, Python, JavaScript, Go, Rust, whatever. That is compiled using an SDK such as Spin to a WASM file. Now this WASM file can run in any platform, any architecture, any operating system as long as it runs a WebAssembly runtime. So in this case maybe WASM time, think of it as sort of a virtual machine, right, but just that it's independent of platforms, architectures and so on. And that's how WebAssembly becomes portable. You can write code in all of these languages and run it anywhere. So for something like this to work, you have to think of the contract between operations and a developer as it is right now, especially in the case of writing serverless apps. What it looks like is you have a proprietary software like Azure Functions, AWS Lambda, Google Functions and so on. And your function either lives in Azure and your entire microservices architecture lives in Azure. And typically your Azure function will not work with your AWS Lambda serverless function, right. You are locked into something like an Azure or at a slightly low level you have a container and you have container registries such as OCI or maybe you're in the Kubernetes ecosystem or you have an app running on a virtual machine. Really we're seeing a future where there's something called a component model where essentially everyone is writing certain components that do very specific tasks which all can work with each other regardless of the language that they're actually written in. So going back to that example you can write code in whatever language you want. You can actually use libraries from all over without knowing what the other language really is because of how WebAssembly works and essentially WebAssembly takes care of the rest. Again just this blows my mind so I hope it's blowing your mind as well. Imagine writing a JavaScript app but using a YAML parser that's written in Rust and using a date formatter that's written in Python without really knowing how to write Rust or Python or honestly without even caring that it is written in Rust or Python. As long as your YAML is parsed and your date is formatted the way it's supposed to be your JS app will run. That's what the component model unlocks. Essentially any Wasm server side app or any Wasm app is made up of WebAssembly modules. Now these can be written in things like Rust, Go, C++ and many more and they're compiled to a core Wasm module. Each of these modules are portable because we said it can run anywhere. The binary size is very small so you're saving on money and you're saving on carbon footprint as well and time. It's isolated by default. It has very fast startup times and no call starts. These are completely open standards so you know you can run it anywhere. With this recent launch of the component model one of these modules can work with another almost seamlessly in a way that you can compose applications. So you see component a.wasm which is a core Wasm module on your left and you see component b.wasm, a core Wasm module on the right. Now one can export the thing it does and the other can import the thing it wants and this way you can write it again in Rust and Go and really have them work against or rather work with each other to create a new component in this case which is component c. And you can see that stack like thing invite next to the Wasm WebAssembly logo. That is actually your memory. As you can see your export and your import is not really interacting with the thing that your business logic is working on because this is the security sandboxed by default. We're actually creating interfaces for each component so that they can talk to other components in the WebAssembly ecosystem. That's what the component model really is. Here is an example of how this would look like in production. On your right you can actually see on the top there is something that says business logic component and there is an export and this business logic is the logic you as a developer. Now maybe you want to have authentication and authorization for this business logic but you don't want to write it from scratch again. So you can actually use a component that does auth for you. So here is in the middle an auth middleware component and you can actually see that it exports and it imports basically there is an interface for it to talk to your business logic. And then at the very bottom you have your WebAssembly or your Wasi HTTP implementation which could be either on spin, on Wasm time, on engine X unit, Wasm cloud and so on. Essentially you can see how these different components are independent components of each other but they are working with one another. So if you are writing business logic and you want an auth middleware component you can go ahead and do so. All you need to know is that it exports and imports and that's how it interfaces with another component. In fact here is a demo that I am going to show you and I am going to show it to you very quickly but you can check the entire code base out on our GitHub right there. So this is a middleware component that the engineers at Fermion wrote which essentially does authentication and authorization via GitHub. So imagine business logic is already written. I have built this program and I am running it locally and then I open it in my browser and it is not yet authorized so I am going to click on login. Now when I click on login it authorizes using GitHub and it authenticates rather using GitHub and then authorizes me to then access the business logic because I am now an authorized user. And if you look at the code you can see different components for authenticate, authorize and a callback which I have originally added to my GitHub app that I did earlier. Again we don't have time necessarily to go through the code base entirely but check it out for yourself and see if it works. It is a very cool example of how the component model can work in practice. So what are some of the advantages of this component model? Well like I said you can write programs in multiple languages and get different functionalities and not really suffer from that 2400 hour problem that we spoke about. But I am going to give you a couple of scenarios related to security where this component model can shine. Now imagine there is a vulnerability in an upstream component in this case we are imagining a vulnerability in the auth middleware component. The good thing is it doesn't actually affect your entire program your business logic can remain the same the underlying layers of your WebAssembly run times can remain as is. You can mitigate this by simply pulling a patch upstream component of this middleware fixing whatever vulnerability was there and everything goes on as is. In fact to take this a step further the bytecode alliance is working on something called VARG check out VARG.io which is in development right now which is an open source registry protocol for things like wasm packages. So in the future you will on VARG you will see something like an authorization or authentication middleware that will be a standard that you can use in your WebAssembly app and not really care about its implementation as long as you know that it is working. Similarly let's look at a scenario where there is a vulnerability but this time in the business logic. Again the layers below it are not affected because we have successfully written it in a componentized manner. So all you can do is mitigate by rebuilding only your business logic there is really no need to rebuild any other component no need to rebuild the middleware no need to rebuild the underlying wasm layers as well once you patch your business logic everything again works as is. So each of these components sort of work individually and there is a layer of abstraction between them which makes this very powerful in terms of security. And let's look at a scenario 3 where there is some problem in the platform itself. So in this case we are saying that your key value store in your WebAssembly cloud is probably done. So in this case the host component is not embedded in the application but here the platform provider handles this and mitigates this problem. So whoever is giving you the cloud like say it's an Affirmion cloud will fix this and then again your entire program works as is. So again your auth middleware is not affected your business logic is absolutely not affected again because of the componentized nature of how this program is built. So you can see why this excites me and it should be exciting you as well. Also just to give you another angle of why the component model can be amazing is to look at costs and sustainability. Typically these two are related proportionally if you have like binary sizes you are being more energy efficient but that also reduces your compute storage and networking costs so you save money as well. If you take an example like a conventional CI CD on the left you see a simple CI script basically for go it's a popular script you'll find it on GitHub. There are multiple go versions for multiple OS's and essentially when you're packaging this when you're doing a build you do OS architecture language multiple versions. For tests you do your operating system in architecture to package. This is a lot. Similarly if you look at literally this is from the Docker documentation you can see that there are a bunch of platforms, labels, outputs all of this done in a Docker container but imagine if all of this was built in a componentized or component model fashion this is what it would actually look at where you have a build which is your build so in this case let's call it the WASM 32 WASI Preview 2 your test basically you just need to test one thing which is your run time because this run time we know runs in every platform architecture OS and so on so all you have to do is one version of this run time and you don't really need to package anything because the components are already packages so you don't have to package anything honestly I don't even need to put numbers or you know benchmarks for this because I think you can only tell how much more efficient in terms of costs and binary sizes and packet sizes and networks and storage sizes this will be and just to add to that WebAssembly in itself is already way more lightweight than some of the other technology we have been using in the past so you see why the component model really is the next evolution for WebAssembly so I hope you are excited about this for next steps it's time to build your first WASM app using spin you can just check up github.com it's completely open source so check it out if you want to read more you can read the blog post about it's time to reboot software development which speaks about the 2400 hour problem if you want to dive a little more deeper into the tech check out the post about composing components with spin if you want to get started building in WebAssembly and spin this month in December there's the advent of spin coding challenge which is designed to get people you know interested in building in WebAssembly there are prizes as well so check it out hope you learned something new today feel free to connect with me on LinkedIn or Twitter or email or wherever you'll find me online go check out WebAssembly and server side WebAssembly and the component model have a good rest of the day and see you soon bye