What is WebAssembly? And what's it got to do with Docker? | WASM vs Docker | KodeKloud

Docker recently announced the wasum integration and published a technical preview ever since everyone has been wondering what this means and why there are blogs out there stating that wasn't will replace Docker and kubernetes and so on and Solomon Heights the founder of Docker tweeted that if wasn't and was he existed in 2008 they wouldn't have had to build Docker since then we've been receiving a lot of questions about what wasn't age what does it have to do with Docker the difference between Docker and wasn't and how does the integration work and whether Wilson will actually replace Docker kubernetes or both my name is and in this video I'm going to try and answer these questions for you but before I begin hit that subscribe button if you'd like to be notified when we release new videos every week so let's begin so what is wasn't so first it is important to understand exactly what wasm is all on its own so I'll try to explain it in the simplest of simplest terms you've also in Photoshop right I mean I remember when I first used Photoshop about a decade ago I had to download this gigabyte sized application then go through this hour-long installation process to finally be able to work with it today what if you could just access Photoshop by going to photoshop.adobe.com right how's this complex application like Photoshop served through the web and run in a browser have you ever wondered how tools like figma that let you create Advanced wireframes can be run right in your browser without requiring any installation or configuration have you ever seen high-end video games being played in a web browser and wondered how that's possible the web applications that we know today are typically built in HTML CSS and JavaScript the structure is built using HTML these are designed beautifully using CSS and then made highly interactive by using JavaScript Frameworks like react VJs next.js and whatnot now we can use these to create beautiful web pages and games however they have their limitations you can't use JavaScript alone to create tools like figma or programs like Photoshop or games as I showed before these are developed in programming languages like C or C plus plus or rust and are usually run as an executable desktop application so how do you port these complex applications to work online within browsers and that's where web assembly comes in you see traditionally programming languages written in a text or code format cannot be understood by computers so we need to convert a given source code written in a programming language to machine understandable code we call this a compilation process and refer to the transformed code format as a compilation Target so webassembly is a new type of compilation Target for languages like c c plus or rush and is used to run native apps inside browsers it is possible to compile the native language code to what is known as the awesome binary with an online version assembler like awesome Explorer or wasn't fiddle or a tool such as M scripting ultimately the generated web was in binary can be loaded and run inside the browser along with the JavaScript code the webassembly code can be loaded into a web app using JavaScript wherever simply apis and interact with each other as needed so now let's see a simple demo to see this in action so first we're going to see how to compile a simple C program and run it locally and then we will compile the same into a wasn't binary and run it inside a web page so here's a code for a simple hello world program written in C that prints the hello world to the screen right super simple we then use the GCC compiler to compile it into a binary we can now see the hello world.exe file here and then when you run this file you see the text hello world printed on screen simple and straight now we will compile the same program into a wasn't binary and run it inside a browser so earlier we used GCC to compile this into an executable and now we will use the M script and tool to compile this Tools in binary so following the documentation from the nscripted website we use the EMCC command to compile the hello world.c file and generate a awesome binary a very helpful additional option is the dash o option of the amcc command that generates a HTML file with the supporting JavaScript code required to load the wasn't binary as well isn't that really cool now we see the hello world HTML file a hello world JavaScript file and a hello world wasn't binary file all automatically generated by the EMCC command now if you look closely into the Javascript file you'll see that the Watson binary is being loaded as a file into the page and now when we view the HTML file we see that the C code has been executed and prints the expected output on the page so we have successfully compiled and at the same C code into a wasn't binary and loaded it within a web page okay so we now understand how awesome helps run complex applications in a browser but is that all wasn't can do if webassembly does a great job at packaging applications and enabling them to run in a browser while limited to just browsers instead of using it to package and run applications anywhere even outside the web now when you compile an application program written in a language like go or raster C plus plus into a web assembly format you end up with a binary that can be executed on any Watson runtime some of the awesome runtimes are wacky a webassembly micro runtime wasn't time wasn't Edge Etc now web assembly runtime are similar to jvm or V8 engine or even Ruby or python runtimes that you must be familiar with already they help run applications written in those specific languages now the webassembly binary however is platform neutral which means you don't need to worry about the underlying operating system or the processor architecture so the application can run on all major operating systems however the application might need access to system resources such as files and directories environment variables or system time these are bound to the awesome module during startup by what's known as the web assembly system interface so you have the operating system and then you have the webassembly system interface which helps the Watson runtime that sits on top of it to access the system resources and then we have the webassembly binaries that run on top of the awesome runtime now furthermore there's no need to worry about running on an Intel or arm processor as the webassembly module runs inside the Watson runtime and executes the awesome binary according to the current host operating system and processor so awesome is the packaged form of the application and its dependencies in a format which can be run on a browser and what C is the system interface that makes it possible for Watson binaries to run outside of the browsers and on operating systems so let's see this in action quickly now earlier we compiled the C code into a wasam binary that can be executed in a browser and now we will compile it into a Javascript file suitable to be executable in a node.js environment now the program is the same and the command to compile is the same we use the EMCC command and specify the source code followed by the Dashboard option but this time we specify the JS file as the output the command now generates a awesome binary and also a Javascript file that can now be run using node.js so that's a simple demo that shows a c program can be compiled into a awesome binary and run in node.js so webassembly enables applications to be packaged into awesome modules and along with was C allows these applications to run anywhere on any operating system and not just in browsers now that concept might ring a bell if you are familiar with containers and Docker because containers kind of work the same way so let's take a look at that next if you're not yet familiar with Docker let's go over it really quickly now if you remember how we executed our C program in our local machine in the earlier demo you'll know it involved several steps so number one you download and install a C C plus plus compiler compatible with your operating system and then you install the necessary libraries and dependencies to work with the GCC compiler and then you configure the path variable to use the GCC command from anywhere in your file system and then you compile The Source program with the correct GCC command then you run the generated executable now let's say you have run this hello world program on your Windows machine you then have to be careful to download and install the CEO C plus plus compiler dependencies and libraries that are windows OS compatible you also have to add the GCC command to the windows path variable and so on now what happens if let's say your teammate wants to run and check your fancy hello world program under Mac system maybe you can then share the C source file with your colleague but they must handle the compiling and running a program on their local machines from the very beginning they need to download and install the compatible C compiler the libraries and dependencies for their Linux or Mac OS not only that if you have used a library within your C program that is incompatible with your colleagues OS version a whole additional nightmare widths this is where you begin saying well it works on my machine to everyone on your team and has historically been one of the biggest headaches in developing building and shipping software so what if you could package your awesome program into one single package along with all the necessary dependencies and libraries and so on in a container that can be up and run by anyone you could provide this container to your colleague who'd up it and be able to run your program along with all the necessary libraries and dependencies perfectly regardless of your colleagues underlying Hardware infrastructure or operating system and that's exactly what Docker does Docker is capable of running one or more containers inside a virtual machine on top of its OS and Hardware infrastructure each container can talk to the others as well as the underlying OS and services but runs in a totally isolated environment practically speaking a Docker container is based on a Docker image which is a set of snapshots of a file system layered together to form a single environment if you look back at our example you'll see we can create a Docker image starting from a base image then add the supporting programs and files and utilities compilers CEC plus plus and so on and libraries and that our hello world C program needs and finally the C program should be added and bundled as a single Docker image that can be used to run a Docker container let's have a quick look at how to create and run the docker container that can run your hello volc program so here we are with our simple C program our goal is to containerize it so we built a Docker image for it for that we create a Docker file the docker file looks like this it is built from the GCC image it is an image that has the C compiler in it in the next few lines we copy the code from the local directory into the image using docker's copy instruction and then we build it using the GCC command with docker's run instruction and then we specify the command to be run when this container is executed using the CMD instruction we then run the docker build command to build the image and then the docker run command to run the application well pretty simple and straightforward note that there are better ways to do this and some best practices to be followed to separate the build process and the executable version but we're going to keep it super simple uh just for the sake of brevity okay so let's compare Docker and wasm now as you probably saw already Docker and wasn't do a lot of things the same way both can package applications and enable them to be run anywhere docker's architecture diagram has first the underlying infrastructure then comes the host operating system and then the docker engine and then we have containers that have the applications libraries dependencies and binaries if you look at the awesome architecture diagram you will see the infrastructure then the host operating system and then the vasi which is the webassembly system interface and that's responsible for providing access to system resources for the awesome runtime and then you have the awesome runtime on which the awesome modules run now if you take a closer look at these two you'll notice some distinct differences well Docker wraps the program and its dependencies into a single package that we call as an image and then runs it as a container a Docker container consists of a full file system utility programs binaries and libraries which appear to be a complete operating system for the application itself in addition it is key to create your Docker image according to the right system architecture like Intel arm MD and so on for example if you have a Raspberry Pi OS running Docker then you should create a Docker image for your C program based on your Linux image and compile it for arm processor architecture otherwise your container will not run properly on the other hand webassembly modules and binaries are pre-compiled C C plus plus rust or go applications these awesome binaries can be easily executed on a webassembly runtime such as awesome time awesome Edge or wagy as we talked about earlier it does not rely at all on the host operating system or processor architecture because it wasn't binary does not contain any pre-packaged file system or low level operating system Primitives every directory or environment variable or clock utility and system resource is attached to the Wasa module during the runtime facilitated by the webassembly system interface or wassce so the awesome modules are not coupled with the host Os or processor architecture this is a major difference between how Docker and wassum works now from a performance standpoint there are some significant advantages for wasm when compared to docker wasn't binaries start up in milliseconds compared to several seconds for Docker containers as such awesome programs are almost native speed when it comes to Performance the size of a Wasa module is just several MBS as it does not have any noise components but a container image may be tens or hundreds of MBS at times if there are too many operating system dependent packages since wasm was built for browser it also runs in a browser of course but one of the key differences is that awesome runs cross-platform whereas Docker has a limitation on specific CPU architectures or operating systems Windows containers don't natively run on Linux and vice versa as we have just discussed awesome is a powerful way to compile and run your existing native code written in C C plus rust or go inside the browser as well as outside of browsers or on top of any awesome runtime while confidently enjoying near native performance high security and quicker startup times Docker enables you to package your application code along with all of its necessary dependencies and ship it as one convenient single image with high portability and runtime isolation features and over the past decade we have invested in learning about containers and Docker and also building infrastructure to support Docker containers such as swam and kubernetes clusters so do we unlearn all of that and relearn awesome now do we have to ditch all of the infrastructure and rebuild new infrastructure for awesome not necessarily what if we took wasam's high performance high security and quicker startup aspects and combined it with docker's high portability features this is where the docker plus was of integration become more valuable than anyone could have ever dreamed with Dockers of awesome support you can run awesome containers parallel to Linux and windows containers which enables you to run your native application code inside a wasam container and share it as a Docker image since Docker makes it easy to build share and reuse your application code and developers are familiar with Docker workflows it is easier to use wassum's high performance and security aspects to build and power up your native applications inside a container environment with quicker startup times so how does it work currently you have Docker engine which is the docker API server that serves all your requests when you run a Docker run command a container process is created by a container runtime called run C so run C is responsible for creating and starting container processes run C exits after the container is created so you need some kind of manager to monitor the container and that's the container D shim now one containerdy shim process is created for each container and it is the container the shim process that initiates the creation of container by the Run C and also monitors and manages the container process and it captures its logs and redirects them and helps you attach the container when you run the docker attach command there is a higher level manager that manages all the containers and that is the container D process now to run awesome containers with Docker we use the awesome Edge runtime this is one of the supported webassembly runtimes that were mentioned before and to integrate the awesome Edge runtime with Docker the folks at Docker worked with the folks at awesome Edge to create a new container D shim called container D wassum shim so in the next demo we'll better understand the power of Docker and awesome integration and note that Docker plus awesome integration is only supported as a beta feature on a special technical preview build of Docker desktop app as of this recording also refer to this article published by Docker on while testing it out by yourselves so as before we first compiled the C program into a wasam binary for this we run the EMCC command and pass in the path to the source code of the hello world program and the output of a wasam file then we build a Docker image from it the docker file looks like this it's built from scratch from scratch means there is no base OS image there's nothing really really there then we copy the hello world.wasson binary into the image and the entry point is the binary S as well and here's the interesting part when we build the docker image now we provide a platform flag to specify that this is a container for wasn't the image has now been built successfully and next we run this using the docker run command and we specify the runtime as io.containerd.wassamedge.v1 and the platform as was C slash awesome 32 and followed by the image name that we just built we have now successfully built an image with the awesome binary and run the awesome container so what's the future looking like the integration of webassembly and webassembly system interface has the potential to change the way applications are developed and run in the future the integration of wassum and wassi is likely to become more prevalent as more developers adopt these Technologies wussy and wasn't can be used in conjunction with containerization and orchestration Technologies such as Docker and kubernetes allowing for more efficient deployment and scaling of web-based applications now while it's possible that was awesome may be used as an alternative to some use cases currently handled by containerization it's unlikely that it will replace these Technologies entirely well that's all for this video I hope you enjoyed and got a brief idea of wasam and how it works with Docker if you liked the video don't forget to subscribe to our Channel as we release new videos every week and don't forget to share this video with your friends if you think this is going to be valuable well thank you so much and until next time goodbye

Channel: KodeKloud

Views: 75,758

Keywords: WASM, Docker, containerization, virtualization, cloud computing, DevOps, Rust, Kubernetes, cloud-native., what is webassembly, what is wasm, webassembly demo, webassembly, docker, wasm, what is wasm wasi, wasi, webassembly react, webassembly projects, what is wasmedge, cloud native architecture, what is webassembly c#, Kodekloud, webassembly binary, wasmedge, wasmtime, wasm runtime, Webassembly System Interface, devops, devops tools, kodekloud devops

Id: 7553XZ0T6pM

Length: 19min 53sec (1193 seconds)

Published: Mon Feb 20 2023