Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Docker+WASM Technical Preview

docker.com

Post reply on HN
Print view View original

151–160 of 178 posts

Re: The Docker+WASM Technical Preview

#151

Post by skohan »

saidinesh5 wrote: post #147
skohan wrote: post #129

Earlier quoted context omitted.

Is WASM typically interpreted? I would have assumed one of the advantages of an assembly language is it would be easy to JIT compile down to machine code.

That depends on the runtime. Some runtimes like wasmtime support both JIT and AOT compilation. And for places where you can't use JIT compilation (like iOS... - which is where most of the users/developers of our app were) there are interpreters like wasm3.

Is wasm3 built in to iOS, or is that something you have to bundle with your app?

Re: The Docker+WASM Technical Preview

#152

Post by saidinesh5 »

skohan wrote: post #151
saidinesh5 wrote: post #147

Earlier quoted context omitted.

That depends on the runtime. Some runtimes like wasmtime support both JIT and AOT compilation. And for places where you can't use JIT compilation (like iOS... - which is where most of the users/developers of our app were) there are interpreters like wasm3.

Is wasm3 built in to iOS, or is that something you have to bundle with your app?

Wasm3 is just an interpreter you can/have to bundle with your app.

There was supposed to be a way to use the webassembly interpreter from JSCore but i am afraid my iOS knowledge doesn't go that far.

Re: The Docker+WASM Technical Preview

#153

Post by timanglade »

bradgessler wrote: post #136
corysama wrote: post #104

Earlier quoted context omitted.

I think you are falling into a “deeply-technical explainer” trap. You’ve been so deeply engrossed in the use-cases of this novel technical combo that they are all assumed understood from your POV. And, this tech is so general that there’s a second trap of “What can it do? It can do anything! Sure, but what can it do??” Again, because I’m your head “anything” is pre-supposed to a narrow set of goals that this tech ful…

What's confusing to me is the "main advantages" Tim describes are the same as Docker, so I'm left wondering what's different about it from Docker? The only thing I can parse out of it that's different is 'apps can also be “unpacked” to run natively on edge infrastructure', but I'm not entirely sure what that means. My best guess is that Tim is trying to say, "now can run your Docker apps on AWS Lambda"?

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...

Re: The Docker+WASM Technical Preview

#154

Post by [deleted] »

emptysongglass wrote: post #133
timanglade wrote: post #92

Earlier quoted context omitted.

> 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 pa…

I have some feedback, though more general: can you please stop pushing your flavor of Docker Dev Environments that only works with your proprietary application and get behind the https://containers.dev standard AKA Dev Containers? You are going to lose this battle because your Dev Environments don't have a lot of buy-in and you're not standardized and open specced. I'd love to see Docker take a more OSS-friendly appr…

[deleted]

Re: The Docker+WASM Technical Preview

#155

Post by [deleted] »

pmontra wrote: post #143
mikesir87 wrote: post #122

Earlier quoted context omitted.

Sorry for the delayed response, but the problem we're trying to help solve is how to help lower the barrier of entry to using Wasm apps leveraging the tool many developers are already using. As an example example, with Docker+Wasm you can use a Dockerfile to build the app in a container image, distribute the Wasm bundle as an OCI artifact, and test it locally using the Wasm runtime. While the ability to build using c…

This should be the copy of the announcement. Finally it's clear what it does. The announcement doesn't explain at all what docker + WASM is. Summary of summary: Dockerfile -> docker build -> docker container with the WASM app and runtime inside -> docker push/pull -> docker run container. However, even if I never compiled anything to WASM I think that it was already possible to build an image with a WASM container an…

[deleted]

Re: The Docker+WASM Technical Preview

#156

Post by mikesir87 »

pmontra wrote: post #141
kodah wrote: post #109

Earlier quoted context omitted.

It might be easier if you simplify it to, "We're trying not to be just the app you choose to run containers with. You can now use non-container runtimes like WASM."

So docker+WASM does not build a Linux container image with the WASM application inside but it builds a WASM application packaged as a docker image and started with docker run instead of (say) an ELF or Windows or Mac binary started with the OS exec, whatever it is? If this is the case I'd leave docker outside the name of the technology. I imagine the confusion. At least one customer of mine doesn't fully get the diff…

> So docker+WASM does not build a Linux container image with the WASM application inside but it builds a WASM application packaged as a docker image

With this preview, we are leveraging the OCI specification that defines how to build an image. Linux/Windows containers are the most common use of this specification, but many other types of artifacts exist (OPA policies, Helm charts, etc.).

When using any of these other artifact types, tooling has to know how to use that specific artifact type and run it (eg, extract the image and run it as a container or extract the Helm chart and deploy it). In our Wasm use case, we are doing the same thing... package and ship a Wasm module and we'll extract it and run it on the new Wasm runtime. That runtime then "converts" the Wasm module into native machine code for the OS you're running on.

> If this is the case I'd leave docker outside the name of the technology. I imagine the confusion.

That's great feedback! While most know us as "the container company", our mission doesn't even talk about containers. We want to help all developers succeed by reducing app complexity. We can certainly do more to help educate folks between the different types of workloads you might be running. We're still very early on in this process, so stay tuned (and keep the feedback coming)!

Re: The Docker+WASM Technical Preview

#157

Post by mikesir87 »

xeonmc wrote: post #142
timanglade wrote: post #121

Earlier quoted context omitted.

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!

It's still not clear to me, so can you bundle source code into your Dockerfile and just have compilation being part of the docker compose step?

Great question! In the demo app we showed yesterday (source here - https://github.com/second-state/microservice-rust-mysql), the Dockerfile is leveraging a multi-stage build where the first stage builds the Wasm module and the second stage extracts the Wasm module into a "FROM scratch" image.

In Compose, the "server" service is running using the image that is produced by that build. It's then handed off to the new Wasm runtime, where the module is extracted and executed. Hope that helps! Feel free to follow up with more questions!

Re: The Docker+WASM Technical Preview

#158

Post by bradgessler »

timanglade wrote: post #153
bradgessler wrote: post #136

Earlier quoted context omitted.

What's confusing to me is the "main advantages" Tim describes are the same as Docker, so I'm left wondering what's different about it from Docker? The only thing I can parse out of it that's different is 'apps can also be “unpacked” to run natively on edge infrastructure', but I'm not entirely sure what that means. My best guess is that Tim is trying to say, "now can run your Docker apps on AWS Lambda"?

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 nati…

So the distillation is something like this?

"Docker images can now be deployed directly to the WASM runtime! This means your AWS Lambdas, Cloudflare Workers, etc. will boot faster and cost less..."

When you rehash what Docker already does, it's watering down the messaging. Even adding "AWS announced support for containers on Lambda last year" in the last reply made the voice in my head ask again, "What's different about it? How is it better?"

Re: The Docker+WASM Technical Preview

#159

Post by vbezhenar »

fulafel wrote: post #113
vbezhenar wrote: post #71

Earlier quoted context omitted.

One benefit of using wasm is architecture-agnostic binary. Right now you can't run x86 binary on ARM or vice-versa. So basically you need to build your containers twice if you have macbook people and x86 servers. And technically those are different images, so there's chance that you'll hit some non-trivial difference. With wasm everything could be simpler.

Docker Desktop can build and run x86 on ARM/OSX and that's how most people use it.

This does not work for me. Java image that takes 30 seconds to build on x86 machine took 40 minutes to build on M1 after which I killed it. So this feature essentially does not exist as it's not usable. I don't think that's how most people use it. I, personally, rent x86 VPS just for docker.

Most images nowadays have ARM version, so probably that's how most people use it.

Re: The Docker+WASM Technical Preview

#160

Post by vbezhenar »

fulafel wrote: post #131
tpetry wrote: post #128

Earlier quoted context omitted.

And it is starting an additional emulated x86/amd64 vm that is emulated. The battery takes a big hit. Now imagine you can run wasm that doesn‘t need an extra vm and doesn‘t drain your battery much faster.

I think the # of people losing a lot of of battery to this is miniscule, especially since the OSX x86 emulation is pretty fast. A bigger peeve is that there is no general reasonably fast cross build ability, to eg build, test and debug ARM images (for runnign on ARM servers) on x86 Linux or Windows etc.

There's no OSX x86 emulation.

There's Rosetta emulation and qemu emulation.

Rosetta emulation is quite fast. But docker does not use it. At least for now.

qemu emulation is extraordinarily slow and basically unusable for anything but the simplest code.

Post reply on HN