timanglade
Joined 19 years ago
Karma
1,718
Submissions
370
Member since
Apr 2
Recent submissions
Comment · 4 years ago
Assuming you had code that somehow could either be packaged as a linux container, or as a Wasm binary, then the advantage of the latter would be that yes Wasm supports multiple CPU architectures out of the box, it also consumes less resources (memory, etc.), will usually have faster start times, and the Wasm security sandboxing is stronger.
Comment · 4 years ago
That’s not quite right. You can’t take an existing container app and just "export" it as Wasm. (Technically you might, but it would require a pretty big re-architecture and re-write, as Wasm doesn’t support garbage collection or multithreading at the moment. It also requires you use a language that can be compiled to Wasm, which can be limiting. Due to this, Wasm — at this stage — is probably best fitted to functions rather than full apps, although that is changing quickly.)
What you can however, is build apps for Wasm (or apps that combine Wasm and containers) with the same ease you currently enjoy when building pure container apps, i.e. see my comment above [0]
Comment · 4 years ago
AWS announced support for containers on Lambda last year[0]
> the "main advantages" [redacted] describes are the same as Docker
Yup, that’s it! If you value Docker to build container apps, we think this will help you build Wasm apps in the same way, and the only container-centric abstraction this Technical Preview uses (packaging artifacts as OCI images) can be bypassed, if you prefer to deploy your artifacts as native Wasm binaries. The latter can be helpful if you are trying to get the full speed & efficiency benefits of a Wasm-native deployment, as the shim in our OCI package introduces a small performance penalty.
[0]: https://aws.amazon.com/blogs/containers/containerizing-lambd...
Comment · 4 years ago
That’s our experience as well… This Technical Preview is an early downpayment, and we’re definitely looking for feedback on how one may could make the Wasm development experience better!
Comment · 4 years ago
Basically yes: if you get value out of Docker for container apps today, we think you’ll get value out of Docker for Wasm apps tomorrow.
Comment · 4 years ago
I tried to answer this above[0]. Instead of trying to explain it again, I’d encourage you to give it a try[1], and if after going through the 5-minute tutorial you still don’t get the point then a) maybe we messed up (and I’ll be sorry for having wasted your time!) or b) maybe it’s not for you (and I’ll also be sorry I wasted your time). It took me a while to wrap my head around this Docker+Wasm thing too when I first heard about it internally — then again it took me months to wrap my head around my first demo of Docker, so maybe I’m just dense!
Comment · 4 years ago
> I'm just sincerely confused at what problem this technical preview is intended to solve.
This is all good feedback, and we’ll definitely try to explain the added value better in the future. The main advantages we see in this technical preview are:
1. Easy, reproducible dev environment to quickly & reliably develop cloud/edge apps that target Wasm, or code frontend apps that target a Wasm backend (for example, as part of a microservice architecture). This is particularly helpful if you build apps that have a mix of Wasm & container components[0]
2. Easy way to share & deploy Wasm artifacts, using trusted infra like Docker Hub, but also Dockerfiles and Docker Compose
3. Transparent, reliable way to deploy Wasm applications to existing container-based infrastructure such as k8s (via OCI images) — but these apps can also be “unpacked” to run natively on edge infrastructure
> is it going to wrap the WASM binary produced by cargo in another layer of abstraction? If the latter, how is this new layer of abstraction different from just using one of the WasmEdge docker containers [0]?
Our approach is close to this. First, it was built with the WasmEdge folks, so you’re correct to detect the similarity. Second, it does wrap resulting artifacts into a OCI image, because we believe that can generate a lot of advantages (points #2 and #3 above) BUT you can also easily unpack the Wasm payload from the binary image at deploytime/runtime if you’d rather deploy your app on Wasm-native infrastructure (as opposed to container-native infra)
Appreciate the feedback. Hope the above helps.
[0]: https://docs.docker.com/desktop/wasm/#running-a-multi-servic...
Comment · 4 years ago
> I don't know any dev looking for this or having a problem solved by it.
Judging by the reception at KubeCon & elsewhere today, we think at least some folks are excited by it. But it’s still early, and who knows, you may be right in the end. We launched this as a technical preview to test a hypothesis and learn from it, and so far the interactions from this HN thread alone have been greatly helpful.
Comment · 4 years ago
"Docker+Wasm" is just a shorthand for the Technical Preview build, which allows you to build both traditional container apps, as well as Wasm apps. Behind the scenes, we try to let Wasm apps be developed largely without interference from any container technology — just giving you a good local environment you can use to code against. That said, if you want, we do offer the ability to run Wasm apps within a Docker Compose application. We do also offer the possibility to package Wasm apps within an OCI image, with an embedded Wasm runtime (WasmEdge) so you can a) easily share these via an image registry like Docker Hub, AWS ECR, etc. and b) easily run this anywhere you’d run a container. That said it’s not mandatory, and if you want the benefits of (a) without the benefits of (b) you can easily unpack the image to just get the Wasm payload and run that however you want. We dove into the details of the approach at Kubecon today, and the video should be coming out shortly.
Comment · 4 years ago
Long live Wasm indeed! Obviously we feel a bit differently about Docker and k8s being in the past — Docker is used by 68% of professional developers according to the latest SO survey[0], and k8s is still growing in popularity at 28%. But obviously the technology landscape changes rapidly, and maybe one day (we hope) Wasm will be at 28%, 68% or higher. We’re frankly just excited about the possibilities, and wanted to help along the way :)
[0]: https://survey.stackoverflow.co/2022/#most-popular-technolog...