 Okay, hello everyone. I hope I'm audible. If not, I can shout louder. That's not a problem. So I'm Divya Mohan and released that I can say is that I'm extremely honored because I really am to be speaking at the Emerging OS Forum at the open source summit today. So I'll be speaking about the WebAssembly landscape but we'll get to that in a bit because I realize that I have not introduced myself and honestly speaking I don't think a lot of y'all know me so I'm a technical writer with SUSE and I'm also an advisor to Avesha. Over and above the open source work that I do at my day job I'm also heavily involved in the cloud native ecosystem as the docs maintain on the Kubernetes as well as the litmus chaos projects and suddenly the cloud native ecosystem is how I stumbled upon into the WebAssembly ecosystem as well and I promise that this was not an intended segue but I'm going to take it. So if you're absolutely into Marvel or DC Comics or any franchise for that matter, you'd probably know that the villain or the superhero actually has an origin story. It basically sets the context really of how they got their powers and how they rose to the fame or the infamy and how they conquered. So basically that's what I'm going to be doing, a bit of context setting for WebAssembly and let's have a look at that. Now this is a no brainer because WebAssembly has the name Web in it so it started right at the origin of the internet which was back in the 1990s and if you look at the page here there's like the first page of the internet for those who don't know and you'll see that this doesn't have like a lot of interactivity and the dynamism that we've come to associate with the Web and we kind of take that for granted but what the internet essentially started out was a document sharing network for among you know folks it's on. So that's of course still JavaScript came into the picture a few years later. A programming language that was written for the Web, JavaScript was made available in the year 1995 if I've not gotten my math and my timeline's wrong and it's ever since become a member of the holy trifecta of the Web that is HTML, CSS and JavaScript. So it's you know in order to introduce more dynamism, JavaScript wasn't alone in its venture we also had plugins like Flash and Silverlight come into the picture. Now I know we were going you know I was going to talk about WebAssembly but this is like a little bit of heavy context setting. Plugins were required and introduced a few years later as a way to contest maybe the rise of JavaScript and you know in the quest to bring dynamism to the Web. For those of you in the audience who don't know I'm pretty sure there are none who don't know what plugins were they were downloadable software that could be used to view multimedia content stream audio video and execute rich applications such as you know games on the web during the early internet days of course. But I digressed a bit there because we're here to understand more about WebAssembly and why it came into the picture. So what exactly was the problem with JavaScript and these plugin things? Well when it came to JavaScript what ended up happening was that because it was so widely accepted and the entry level barrier was low I don't know who said that but anybody who works with JavaScript right now does not really think that. The entry level barrier was low it ended up becoming a sort of de facto programming language which is fine but it also ended up becoming the de facto compilation target which meant that any language any application written in any language if you needed to bring it to the web you need to necessarily compile it to JavaScript and this wasn't super optimal given that JavaScript wasn't designed to be a compilation target in the very first place. Additionally when we talk about performance intensive applications like say your Figma or your Photoshop or an application running an AI ML workload these started throwing up glaring inconsistencies in performance. We're all technologists here so I'm not really you know going to go into the details of what is a strongly language and what is a weekly type language but being a weekly type language gave JavaScript as many drawbacks as the benefits and the competition wasn't really that great from the plugin side of things because it was a downloadable software and anybody who has used plugins knows the amount of viruses that came along with it so it was a massive security nightmare and the compatibility of these plugins across devices or operating systems didn't really help the case either. So as it stands today Flash by Adobe and Microsoft Silverlight stand discontinued in terms of usage and our quest for alternatives began you know way back then and with all these problems in our head. So there were a number of efforts underway which led to the you know cropping up of the ASM.js specification one of them being the introduction of Rust then other being the M script and initiative but it was the ASM.js specification that made its way into the ecosystem nine years ago moving us one step closer to WebAssembly as we know it today. So what is the ASM.js specification I've borrowed this because I think it's a very cool slide that was presented in the cloud native WebAssembly day it's by Bailey Hayes you should definitely go check her talk out as well because it was a fantastic keynote it's she called it the greatest hack ever and I kind of tend to agree with her because ASM.js is basically a strictly typed subset of JavaScript a couple of slides back when we spoke about disadvantages of JavaScript I talked about weak typing being one of them with ASM.js only top level named functions and simple constructs were allowed again throwing back to a slide I showed before there was the whole process of compiling to JavaScript which is a major hindrance for bringing applications written in other languages onto the web ASM.js leverages the M script in a compiler that's LLVM Clang based for transpiling C or C++ code into ASM.js now obviously this was crap too because we're talking about WebAssembly why was that the case so the ASM.js spec was a disjointed effort and by disjointed I mean that one set of folks were already working on the ASM.js specification but there were other initiatives like the native client and the portable native client initiatives by Google to bring languages like C++ C to the front end although there was an eventual convergence with all these efforts being you know taken up by different industry folks there was a recognition that there is a need for standardization with respect to you know this direction so that's how circa 2015 WebAssembly was announced as a standard now the initial implementation was based on the feature set of ASM.js and the MVP that was announced in 2017 and it's still what we're working with today the public working draft was announced I think a couple of months back I think April for the second version but it's just a draft it's not you know nothing's there yet but let's let's take a step back what on earth is WebAssembly it's kind of a misnomer at this point given that it's neither web nor assembly you know neither it's it gave us to the web show but it's not exactly assembly level language at its core it's basically a compilation target and this means that it's basically more machine friendly than human friendly in the sense that the output is that of a compiler and it will be in the binary code format so when you're speaking about something that's there in the binary code format you unless you are an extreme enthusiast in the space you will not be interested in going through the you know reams of pages you get as output so we have a textual format within the WebAssembly ecosystem to complement that so that you know if you're an enthusiast or if you are actually you know interested in writing compilers and stuff like that um you can use that um like I said before it's um you know it was designed for the web initially but it has extended its reach far beyond to the server side and other environments as well we'll see that in a couple of slides though um so yeah I mentioned that WebAssembly typically has a binary code format right and some of you must be wondering how and how do we actually end up writing real world applications or leveraging it for real world applications uh primarily because achieving a lot of the frills and fancies that we have with real world applications um involves networking it involves accessing memory bunch of other functions and WebAssembly has a specification and you know the core spec does not simply allow for that which is why the next section of the presentation here will be dealing with the wider ecosystem which is the component model um including the component model uh the WASI spec and you know folks and projects involved in this space so um but before we dive into the WASI spec which is specification for the WebAssembly system interface um this is what Solomon Hikes who's the founder and CEO of Docker had to say about it um when we started out as an industry we were heavily reliant on our um you know physical machines we used to run applications on them in fact the um first web page that I showed right at the start of the presentation ran on our next computer at Sun um we progressed from there to maybe you know having virtual machines on the same physical server then you know moved on to um cloud native uh microservices architecture with cloud native um tools then we obviously moved on to uh you know having them in different clouds and um we're not going to dive too much into the specifics but what containerization and transformation to the uh microservices based architecture aim to do uh was to actually lighten the divide uh between um the traditional development and operations team by actually letting developers take um you know developers worry only about the applications they write but that is still not the case uh with containerization we still have to worry about the apps app specific libraries bring in web assembly and that last layer gets abstracted away as well and that's why Mr. Hikes says or has actually tweeted what he did back in 2019 during the announcement of the wasi spec that if it were existing back then like during the announcement um of docker back in 2008 if um draw draw um docker probably we wouldn't have to go through the entire containerization bennett's revolution that we are going through um so what is wasi exactly um like i said before uh web assembly being a compilation target and a low level language uh doesn't have all the frills and fancies that are typically associated with a high level programming one uh memory network and file system management are some of the absolute basics that you would require when working with a real world application and when you're in a browser um wasm uses the browser apis to do this but like i said uh it has gone beyond the browser and we would need something to um need something for web assembly to actually interact with the system the actual system so in such an environment prior to the introduction of wasi uh there were no standard set of apis like we have in the browser side so that wasm could use uh it to interact with the underlying host the wasi spec sort of gives web assembly that capability to do uh to do it with the various proposals that are listed on this slide um of course this is not the only um you know uh important specification within the ecosystem but it's one of the uh important ones along with the web assembly gateway interface specification which is mentioned in the very last point um and now that we've spoken a bit about wasi uh you'll appreciate the component model uh even more because um it takes that reusability of code a bit further uh the component model defines an architecture platform and language agnostic format for representing executable code a web assembly module uh may import functions uh global variables etc from the host runtime and can export that to the host however there's currently no way to combine modules at runtime and uh there is no standard way to actually um you know pass high level types like strings and no records across module boundaries the lack of this composition uh for a module meant that means currently not meant means uh that modules have to be statically linked and uh you cannot dynamically link them at runtime um and they cannot you know when we spoke about web assembly the main thing was that we wanted it to be portable but with with this thing uh with this drawback it cannot communicate with other modules and as a result uh there's no way for communication um leading so because of the lack of communication there's no um way it can be portable um the component model basically allows um for this uh you know communication in a standard portable way and the dynamic uh linking of modules at runtime uh via provision of three features on top of the core specification uh one is that of the interface type the second is that of uh module and component linking and the third feature is that of the canonical application binary interface um so i've included a link to the uh you know component model um spec and the wasi spec at the end so you can reuse that uh after the slides are up i promise to put them up by the end of the day but yeah um once we speak about uh the component model uh the first thing that comes to mind is where do we run it uh where do we run the things or the applications that we write leveraging web assembly right once run anywhere was a dream we had begun to dream with java uh it soon transformed to write once debug everywhere and uh with javascript we sort of managed to come a bit closer to the original dream because it was the default programming language for the web but while running native code in the browser what tends to happen uh is that each time the source code gets transcribed to the relevant programming language by a compiler uh it leads to a lot of code enlargement uh the workaround is to use a compiler with specific auxiliary functions and uh based on the different features like uh wasi support um smaller troop uh smaller footprint and true compatibility with the right ones run anywhere um paradigm we have all these different run times to support web assembly currently and this is not an exhaustive listing because this would probably span like four five slides currently so i have just uh hyperlink the uh you know listing in the slide and it'll be available when they are put up um now next up is a quick look at all the major platforms leveraging web assembly to help uh solve various use cases uh for me on here uh i believe they're there in the sponsor showcase as well um they work on what uh web assembly uh powered cloud tools um suborbital uh it aims to turn anything into functions as a service fast platform uh was in cloud as a cncf project here um and it enables you to write business logic anywhere uh right from the edge to the cloud uh again not an exhaustive listing since it's an ever expanding ecosystem and um uh these are the various compilers available and interesting space to watch out for because um it's an it's an exhaustive list and the complete list uh with the github link is included at the end with the resources um it's an interesting space to watch out for because a lot of these compilers are currently in the stage uh wherein you know the work uh is completed but it's not currently uh it's usable but it's unstable so um it'll be interesting to see how uh uh you know work goes on in this particular ecosystem and uh when we talk about compilers the how can we leave languages far behind because the very first question that gets thrown at me when i speak about anything web assembly is what languages are exactly supported today and do we have to actually learn uh rush to learn web assembly so the answer is no uh there are um you know three different types of languages that are currently supported by web assembly uh you have like uh web assembly specific languages that have been written specifically uh you know to support web assembly that is assembly script is um you know one of the examples uh then you have scripting languages like python which now offer support for web assembly and of course there are higher level languages like cc plus plus rust that have exemplary support for web assembly as well so no you do not have to learn rust for it but if it's if you do choose to learn it it's a great language um i previously also think i referenced this uh transition from um on prem dedicated servers to um uh you know a more cloud native um declarative sort of architecture in the slide with Solomon hikes uh it's this is a fantastic pictorial depiction of what exactly uh you know web assembly tries to achieve um this is one of the keynotes it was there in the previous year's kubecon cloud native web assembly day and uh it's actually pretty self-explanatory in the way that uh you know uh the transition is at least um you know aiming i mean we at least aim to achieve in terms of you know the move to web assembly so the last level is what we aim to abstract away and uh the whole uh idea is to tightly couple cloud native and web assembly so that we can have uh we can have that in uh you know the near future uh now again uh not an exhaustive list but i personally work with kube burden a bit more so i can speak to that um so these are some of the projects there are um you know others that offer support for web assembly like uh opa also recently um you know announced so i haven't included that here because i had made the slides prior to that but uh yeah so uh kube burden basically is uh um project that leverages uh web assembly so that you can write your kubernetes policies in which of a language is most comfortable to you um caveat obviously is that uh the language needs to have a compiler that can translate it to worsen um but uh this is again a space that's growing because uh like i said that last level of abstraction um being removed is an interesting thing for a lot of folks in the cloud native ecosystem and the web assembly ecosystem alike so this is a place you can watch out for in terms of more developments in the future so where can web assembly be actually used um is the thing now um because i've spoken a bit about uh what it is uh its intersection with cloud native and um you know the transition and what all languages but uh it uh essentially what we try what we're trying to do with web assembly is that we're taking application code and um um we are trying to have it run anywhere whether it's on the edge whether it's on the web whether it's on your on-prem systems if you have any um whether it's on your desktop whether it's on your browser anywhere so um that's the end goal and uh we've sort of achieved that and i think a couple of slides further you'll be able to see a graphical um description of where all web assembly is being used currently uh but um there's a small example of how web assembly is uh being used currently uh in you know uh the space uh where flash and uh sorry flash and silver light used to be you know the pioneers so uh rafael which is a web assembly powered um web gl actually is the um uh powering um powering source behind flash emulation for prime video zoom and google neat and this is not a shout out or anything but it's just one of the things that i thought was interesting in terms of your life application but yeah this is a whole uh thing of where all we have um applications currently uh this i believe was made in i think 2019 or early 2020 so um there are far more uh you know branches right now so i i recently read about cloud flare uh supporting web assembly as well so it's uh it's not the only this is not like the only map but uh we've gone beyond the web as is clearly illustrated in this slide um that being said i um almost at the end so thank you for your patience um so what exactly is the future of web assembly and where are we headed so um currently it's not the default compilation target uh let's uh it all that's supported across all the major browsers it's um not the default compilation target across server side and client side applications sorry browser side applications so the future of web assembly is probably you know in this direction of becoming the default compilation target to have this have like that last layer of abstraction um you know cleared off um and of course with uh the component model um and was the spec enabling a reusability of code um we are looking at um more um standardization around software development and language neutral um application development as well um so these are some of the community and learning resources that you know are prominent in the ecosystem they're not the only ones though um so uh wasm.builders is a fantastic place uh wherein folks actually uh starting out or experienced are uh you know talking about their uh applications with web assembly the bytecode alliance um the cloud native computing foundation the confidential computing consortium all of our when and the w3c community group all of our vendor neutral homes uh for you know uh projects of web assembly and uh a huge shout out to all these um learning resources that i actually used when starting off um uh lin clark's blog in particular is a fantastic resource uh for anyone trying to get a grasp of what um the internal workings of web assembly are um uh she explains it in a really really simplified way uh uh similarly with the weekly newsletter that uh call in uh runs that's another amazing uh source of uh you know information to keep yourself updated but uh i guess that's it from me and thank you so much uh for you know listening in with all your patients and i hope you have a fantastic time thank you