WASI is the new kid on the block.
Вставка
- Опубліковано 17 тра 2024
- We talk about where the container world is at the moment and how the introduction of WASM, WASI and WAGI will disrupt cloud native software development forever.
00:00 - Intro
00:43 - Disclaimer
00:57 - WASM, WASI & Docker
04:59 - .NET and WASI demo
11:04 - WASI based .NET Microservice with WAGI
15:24 - WASM to OCI
- Preview of WASM support in Docker:
www.docker.com/blog/docker-wa...
- Spin framework
www.fermyon.com/spin
- The Byte Code Alliance
bytecodealliance.org/
- .NET WASI SDK
github.com/SteveSandersonMS/d...
- Updates on WAGI
deislabs.io/posts/wagi-updates/
#dotnet #wasm #wasi #wagi #docker - Наука та технологія
Thanks for sharing this. I've been super interested in WebAssembly since I first head of it a few years back. I kind of lost track of over the past few months but this video along with the latest .Net announcements about it motivate me to start learning for more about it. Thanks again!
Interesting. Hope you can do further video on this subject as you dig deeper.
Excellent content. May the future get here faster!
Very informative, thanks! This is incredibly exciting!
This needs a cool tagline, maybe something like “Write Once, Run Anywhere”!
Awesome technology! I am keeping my eyes on this also. Very good video, congratulations.
Very useful, and I like the way you explain. Subscribed!!
This is all very promising but everything with WASM is always “just around the corner”. I first heard about WASM back in 2016 and we’re now headed into 2023 and we’re still waiting and discussing “what will be” at some point in the future.
I feel like the kids in the backseat asking - “are we there yet? No. Well just wake me up when we get there.“
We have used WASM in our core products for years now. I know that large companies like Adobe and Google are using it. I dont know what youre waiting for :)
well, WASM certainly doesn't step in as a replacement for what we do with Docker containers. Pretty much any existing code, no matter how its implemented, can be packaged and made to work correctly in a Docker container. So we can have Golang apps, Python apps, C++ apps, Java apps - andvwe can package in useful additional tidbits from the vast Linux eco system - which is extremely handy, powerful, and flexible to the max. And they are then all nicely packed with their respective dependencies. IOW, Docker containers don't impose awkward limitations.
Awesome content!! Baie dankie!
Really helpful thanks Fanie!
WASI sounds a lot like the Java VM concept. Wasn’t one of the main points for the container was that it had all the needed dependencies and configuration to run the application.
That's what I was thinking as well. Even more so when you think about the capabilities of Graal VM. I guess the major difference is that Java never really made it into the browser
Thought the same. The whole world made this long journey through containers and so on to arrive at a point where the Java guys already are for nearly 30 years or so :D
the concept is the same, but the Java VM was developed with a specific language in mind (Java). But WASM was developed as a general compilation target for any language. In WASM you have a much smaller runtime, because you don't have build in garbage collection, reflections and so on.
It's not really the same thing. I'm sure having all dependencies in one neat package was part of why Docker became so popular, but the main purpose of Docker is isolation. Containers need explicit port bindings and explicit access to only specific parts of the file system. The point of WASI is it gives you the exact same safety through its sandbox. It has the same restrictions as docker of having to explicitly define everything that is allowed to interact with the host system, but without having to use virtualization. The purpose would be to replace cloud hosted solutions where untrusted containers are running on hardware that's managed by the cloud provider. Instead of virtualizing a whole OS for each container you would just run a fleet of WASI applications that are each in their own sandbox and only have access to their own storage and nowhere else.
@@DefnDKMC Docker doesn’t use virtualization on Linux. There is almost no overhead. It uses Linux kernel features. WASM doesn’t make sense as a replacement for containers. It is another option, but it doesn’t change the game.
Very cool!
Thanks for sharing
Write once run anywhere? Sounds like Java from even the 90s.
The end was epic and no regret I watched to the end.
you lost me whe u turn on a power shell lol great content thanks!
Dankie Fanie. Lyk vir my jou kanaal is vandag gekies deur die algoritme vir een of ander rede. Enjoyed the content :)
This is great
👍 thanks for sharing
Love your style of explanation, and the conscise and very important content for the future.👍.
One wish, can you unfold the eco-system in the relation to the RUST language.
THX
"Write once, run everywhere" is philosopher's stone but programmers version.
how do you access the filesystem when compiling to wasm, is there a way to mount some part of the disk as special fs visible to wasm binaries or would this require DB blob storage/using some kind of cloud storage provider ?
Also, are they any performance considerations?
WASM is sandboxes by design but in combination with WASI the host would arrange file IO and it will "just" be available in WASM land.
Like it was said it is not about it replacing containers ...... Running a container have never been about running a single app ...but to run a group of process in the same separated (not always) process namespaces......single app in a container seems to be a good idea since it makes things are much more potable and manageable ..... This is why kubernetes became so big so fast.
Well this technology does not seems like something we have not seen before like JVM....which was sold as "build once run everywhere" and turned into to be "build once debug everywhere"
I can see a use for this for tiny to small web apps ... Large enterprise system will sill use containers and kubernetes as life are more than web apps
Nice video.
Subscribed your channel.
All this is great but how do you connect this stuff to graphics and networking? I heard you still can't manipulate the DOM so you still have to go to javascript.
If your question is more towards UI in a browser, I suggest to check out Blazor WebAssembly with pure .NET code running in the browser, manipulating the DOM without the need for JavaScript - dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor
seems more like a node for webassembly instead of a replacement for containers.
It's not about replacing containers.
I agree that this is a nice way to think of it.
JS on its own cannot do anything useful even if you have an engine like V8. In order for it to do useful stuff on the web, the browsers provide the Web APIs (like dom and fetch). In order to use JS as a general purpose language you replace the Web APIs with a system API layer, which what nodejs does.
WASM does nothing useful on it's own on the web, it doesn't even have access to Web APIs, but it does have a Foreign Function Interface (FFI) that allows you to call JS, and with some JS glue code you can give WASM access to the Web APIs and do useful stuff. The same but providing a system API layer is what WASI aims to provide. So seeing the relationship between WASI -> WASM as the same as Node -> JS is a good mental model. I would argue that it is a similar relation to the one between libc -> C as well.
I think the change here with docker, is that for a docker container running a C application, you need to bundle libc (for linux x86-64) and your C application within you container image, making it linux-exclusive and x86-64 exclusive. With WASM/WASI support, the WASI layer lives on the docker side, and you only ship the WASM bytecode in the container. Making the container image potentially smaller, and multiplatform at the same time.
Not that this is a novel idea, since it's what Java already promises with the JVM. I think the difference with a Java-like approach is that WASM bytecode can be executed "more directly" than Java bytecode, and that WASM provides this separation between the bytecode and the WASI system layer, whereas Java couples the bytecode and system layer together into a single JVM specification.
Node enables us to run JavaScript outside the browser. WASI enables us to run Rust/.NET/C++/etc. outside the browser, but a little slower.
@James that’s my point! I don’t see what need this fills. We don’t need WASM to run native code outside the browser.
@@pchasco portability and interoperability. Like a better JVM.
I like the idea that I could deploy a wagi gateway, then break a monolithic api into microservices that each build and publish to ACR and get executed behind that gateway. I need to look more at wagi but I am guessing the wagi gateway would still sit behind a "proper" gateway (like traefik or az app gateway etc) - as it looks like wasg executes the api wasm workload locally so there needs to be at least a LB in front of it routing traffic to it appropriately for that to make sense - no doubt also handling other things like authn / authz, ssl etc etc. I need to explore more with this architecture - thanks for the informative video.
Thanks for the feedback! Have you seen Spin? www.fermyon.com/spin
would love to see a performance and I/O comparison between using native runtimes vs web assembly. does it also have faster startup, etc.?
It probably depends on the language?
@@FanieReynders I totally agree. That's what makes it even more interesting to think about! Already 40 languages supported I saw
WASM does not typically perform faster than the same code compiled natively. There are many factors at play here, but often it has to do with JIT overhead and instrumentation, progressive compilation, and that JIT often does not optimize as aggressively or completely as AOT.
I have a experimental web framework written in async Rust that can be cross compiled to target wasm32-wasi which can be ran with wasmtime runtime. Per thread IO throughput for hello world http/1 requests is about 1/3 of what the same native code can offer. Unless I did something horribly wrong it's safe to assume there is still a long way to go performance wise for server side wasm.
I really love how you do everything from terminal and vs code
Dankie Fanie! Baie insiggewend.
But this wasi support has to be built for every single language out there right? unlike docker which will run any xyz software / language regardless. Its the same concept as Java and JVM except you can now use this across all languages IF in case wasi support is brought to that language. Which is a big IF
Interesting 🤔
Ey Brother Man. Picked up that you may be South African. Just Subbed. All the best.
I feel like the most important question for me, as a programmer, hasn't been answered (90% of the way through): what's implementing all the usual platform/os features? What console is it outputting to if it's not a bash shell or command prompt? Does it have a windowing api like java? How do you access controllers? How do you write, say, gpgpu code on it?
I'm about to look it myself, but I couldn't concentrate once those fundamental questions were left hanging 😅
Cool video! One thing that is often missed in the docker vs wasm debate is that real world apps often need extra files (configs or extra modules) to run properly. So it's also in this sense that wasm containers make perfect sense together: you package your wasm file and "all the environment that it needs" into a container which you can push to a registry.
Wouldn't that include things like ssl certs, api keys, etc? Is the idea that you'd be committing those to a registry? Would you need to have different builds for each environment?
@@ehutch79 no those are secrets and the container is supposed to abort without the proper secrets. But you’re right that some embed them anyway thinking it’s fine to push it to a private registry. I disagree. That’s how secrets eventually get leaked.
Secrets and configuration belong to the environment and should not be included in any compilation
Like (check) Bell (check) Subscribe (of course) Comment: Excellent content, well explained. Excellent production. I'm glad that YT suggested your channel. Keep the good work!
Error: Cannot find 'wasmtime'. Tried installing wasmtime: dotnet add package wasmtime and it says compatible with all modules and yet same error. Wasmtime.Dotnet.dll is in root of the project.
Not a VS code user typically so forgive my ignorance about installing packages.
Wasmtime is a runtime nothing to do with .NET and you need to install separately. You need the experimental Wasi.Sdk package (don't forget --prerelease) to your project to build wasm and run that file with wasmtime.
@@FanieReynders Installed: wasmtime-dev-x86_64-windows.zip from wasmtime website and started new project and Installed wasdi.sdk like this: dotnet add package wasi.sdk --prerelease ... same issue.
You should be in the same dir as your csproj file. Package does exist www.nuget.org/packages/Wasi.Sdk/0.1.2-preview.10061
@@FanieReynders I installed Docker from the NuGet but I didn't know that wasn't Docker. I installed Docker Desktop from website, followed the tutorials to create an instance and now everything us running. Thanks
Using command output and mapping it to an endpoint - sounds an awful lot like CGI. If I ever do this, I'll make sure to put my wagi files in a folder called cgi-bin...
In the tech profession it doesn’t matter that a tool is the best, but rather the one for job security is all that matters. Ie if your company uses Docker and a bunch of other complex tools, under heavy stress, and you raise your hand and pitch for WASI, your colleagues will get u fired anyway as you disrupt their stability to pay rent, despite making all the sense in the world.
For CGI model to be compelling for dotnet backend api development (it seems to be quite a divisive topic among developers in general) I think we'd want all the value of its simple programming model - whilst also being able to lean into asp net core framework for non trivial use cases. The way I see that personally - is we'll want to see an entry point method that we control being invoked, as you've shown in your demo app, but also be able to invoke a minimal api or mvc controller, from a cgi request - where needed. I think wagi would also need to support pooling / reusing processes (like fastcgi) if it doesn't already- as otherwise the perf penalties to pay per request would be prohibitive for many teams e.g start up, loss of in memory cach, connection pooling etc etc (even if they don't need all that performance - no one likes stepping backwards in that department)
Sooo.... It's Java Byte Code all over again?
TOML: Tom's Obvious Minimal Language
As time goes by, Kubernetes have wider and deeper adoption into the world of server infrastructure. It is good and it is popular. So I really don't see what is the benefit, other than bringing .NET into the fold, I guess, that this WASI can provide, "around the corner as always."
A few things: Kubernetes is an orchestrator and provides cluster management for containers, think about it as the ship. WASI is a standard interface for hosts to run WebAssembly "containers" and .NET is a framework for languages like C# and F#. Please don't confuse the technology. .NET has nothing to do with Kubernetes nor WASI has nothing to do with replacing containers. K8s should be able to run any OCI compliant containers (eventually).
Totally expected Rust vid. :D guess not this time. (youtube sent me here)
Look ma, its Flash (AS3) all over again but with a different name
Just way more secure and part of an actual web standard.
@@FanieReynders I suspect Flash was used by more people than Web Assembly. Which would make it more standard than WA... it got killed by temper tantrums and strategic moves, not really security.
But yeh, the good thing of WA is its open source
For those asking about WASM vs JVM twitter.com/solomonstre/status/1111140745824501760
Every other sentence a new technology or program is introduced. Docker seems much simpler in comparison!
I hope this never sees any kind of real adoption in production. It's a cool toy for shipping something cross-platform and easy to distribute (probably great for development environments), but there's no way that it could ever compete with the performance of code specifically compiled to run on the architecture that's serving it.
There's actually a world where WASM/WASI could actually be faster for people coming from languages that're already interpreted or compiled to less efficient bytecode, but you'd be crazy to use it to deploy anything other than that (e.g. services written in c/c++/rust/go/etc which truly compile directly to machine code without a VM). Nobody is compiling postgres or redis to target WASI for production. Conventional containers are here to stay, webshits.
Please keep your comments respectful!
Yes, yes... compiling to a common runtime. Sounds a little like Java to me. I don't think this will be a use case for everything containers are used for now. It's a new island, maybe a useful one, but I don't see a fundamental difference to things that were before.
This guy sounds South African :)
sigh, Docker is a tool set, Containers existed prior to Solomon, they serve more value then running your code as a Developer. In 2022 I'm surprised you think putting a video out like this won't be met with pushback. This week I deployed OpenSearch for one of my customers, you know how I did it? Containers. Next week I'm deploying Hadoop for a customer; containers. This is gonna get repetitive, Kafka a few months ago; containers.
I get you're feeding the algorithm with clickbait titles and thumbnails, but when you get into the meet of your video, upfront you should scope your comments with context. Bare metal isn't dead, VMs aren't dead, Containers aren't dead, and Serverless isn't dead just because WASI solves a problem. It's the same old adage. The right tool for the job. Just because dotCloud and Docker are incapible of running a successsful business doesn't make them the care taker of everything Containers.
The video is not about replacing containers.
Incredible how all these DotNet Devs get so excited for something you can do already with Nodejs since long time.... 🤷
Sounds like the Java VM from the 90's but more complicated, and most likely slower.
It's way simpler and runs near native speed.
@@FanieReynders Docker container plus a headless web container vs the JVM is not simpler, it's more complicated, guaranteed. If it's faster or not needs to be evaluated by doing the same amount of work with both with multiple of examples.
WASM+WASI is not dependent on Docker or anything to that sort, and besides has nothing to do with the web. :)
That wagi thing gives me cgi-bin vibes
Java is like Skype, and WASM/ WASI is like Zoom
that doesnt make any sense
@@charleslatrom7658 exactly
@@charleslatrom7658 old vs new.
@@charleslatrom7658 java came with similar idea... code once run everywhere... but now when we actually needed it, its almost gone and replaced by new kid like WASM
That already existed 20 years ago and it was called "Java applets".
Not exactly. WASM is part of a web standard and WASI brings it out of the browser.
@@FanieReynders Java was too, there exists an html tag name "Applet". And you were able to manage the same code for desktop/server & applet. (and the java moto was "compile one, run everywhere")
You said it, currently WASM is a sort of Flash. It is promissing.
And reinventing the wheel is a human habit.
NO!! As the top comment points out, Java VM was the same concept. My first job after college in 1983 was to write code that was compiled into “p-code” or pseudo code. The problem with p-code or Java or any other similar concept is the code is NOT running at full processor speed.
The code in a Docker container runs at the full speed of the processor. There is no reinterpretation, or interpretation or translation or anything like that. It is at full speed.
And this isn’t new. Not in any way shape or form. The 1983 version of p-code was not new at the time. Interpreted code has been around … well, since Lisp which is the 2nd oldest language.
Indeed…. Why not just execute Lisp???
Go back to school… study your history, computer architecture, language developments, etc. You are lost.
I just want to stop using WSL on my god damn windows
What is stopping you from using Linux?
@@FanieReynders company policy
I don’t see WASI as a game changer. WASM still doesn’t perform as well as native-compiled code. In fact, it doesn’t always perform better than JavaScript. To me, WASI seems like a novelty. It doesn’t run faster, it doesn’t add more features, it doesn’t have better tooling. To me it seems like an unnecessary abstraction layer that only saps away CPU cycles. It does open the possibility of running on Windows without WSL, but who would want to? Windows is expensive. Linux is free. If I’m deploying a cluster, I don’t want to pay licensing fees for each node.
WASM is not Windows specific. It's a thing on its own. The aim of WASI is to bring standardisation to the mix in order to run securely and consistently everywhere.
@@FanieReynders yes, but what I mean is that Docker only runs on Linux because it relies on kernel namespacing for process separation. Docker on Windows runs on WSL. With WASI, you could deploy sandboxes processes to Windows without WSL.
You said that WASI is a “game changer.” I’m simply saying that I don’t see it that way. It hasn’t changed the game at all. Neat tech. Probably overdue. But I don’t think it is going to change the world like containerization did. Node/Deno/Bun enable you to write server software with web tech. WASM enables you to write web software with typically native-compiled languages. The idea of running WASM on the server seems like it missed the point. WASM isn’t necessary if the code isn’t going to run in a browser. Just compile native code.
@@pchasco there is a possible development savings if business offers same app service cross platform. If a bank app allows client to access their dashboard via browser, Mac, Linux, windows, but now just write everything in web assembly.
But in reality, u still have to deal with screen pixel scaling, system level security and library issues (.net family, Mac OS and ios, linux/android land mines). So at the end, benefit on development maybe limited to common container standardization, changing 1 out of 10 game, is not really what I would market as game changer.
WASM is faster than JavaScript. Just not faster when doing DOM stuff because it doesn't have DOM access.
Speed isn't the only goal. WORA with a secure universal system interface.
@@pchasco compiling to native still required multiple builds and working with different ABIs. Plus there is no sandboxing or security. WASM / WASI are basically smaller docker containers
Zoomers created Java.
maar Fanie... microsoft java is nie my taal nie, yster oksied en google taal is beter ;)
Wasm has been around since like 2017 and it’s basically got almost no usage. Hardly the new kid on the block. I highly doubt it will ever surpass docker. Lots of languages don’t/can’t run under wasm. Plus the compile once run anywhere is meaningless. All servers run on Linux. You can save 3 minutes compiling for no use case, whoopeeee.
Interesting perspective, although the video is more around WASI rather than vanilla WASM.
@@FanieReynders semantics.
@@boot-strapper are important
ARM
No more alpine.
what's with the hate on docker?
There is no hate towards Docker. Both Containerd and Docker are solid platforms.
So.....what u want is the jvm all over again 🙄
But platform independent, faster and way more secure.
@@FanieReynders as a dev u know where ur deploying. That's never been what docked was solving. Also you've just imediatly lost the argument by saying faster and more secure.
Speed and security depends on how you write software more than what it gets compiled to. Any professional dev would know that.
Also nothing is faster than a binary. Just pick the right language that has cross platform support (if u need it), like go, and be done with it.
You'd need actual cross platform binary support then ur building a frontend app, in which case when pick more appropriate stack.
The purpose of the video is not sell you WASM. Many factors impact the security and the speed of any solution, not just the code.
@@FanieReynders man al ays asked himself "can we do it" but he never stopped to ask "should we do it"
That happened we I th JavaScript. And it's happening again with was now. Lol
@@FanieReynders Not really sure what the purpose of the video was. Hykes makes some ambiguous comment that WASM + WASI could serve as a replacement for docker, then the rest of the video details nothing about how WASM + WASI isolates processes, networking, or filesystems.