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

61–70 of 178 posts

Re: The Docker+WASM Technical Preview

#61

Post by timanglade »

lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

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

Re: The Docker+WASM Technical Preview

#62

Post by nateabele »

timanglade wrote: post #44
nateabele wrote: post #34

Earlier quoted context omitted.

Hey Tim, I appreciate your willingness to engage. What I'm getting at is a bit more pointed. In terms of composability, Docker and WASM are opposites: Docker requires a stand-alone runtime, and an orchestration layer, etc., whereas a WASM module & runtime can be embedded directly into my application, into a browser, or into (comparatively) simple, time-tested tools like Apache[0]. So, to your point, the opportunity h…

No disagreement here! Just to contextualize: Docker — the company as it exists today — is singularly focused on the development experience, i.e. the inner loop of code/test/build, not the outer loop of deploying to production (which is largely controlled by cloud platforms and k8s at this point). I know that separation can seem arbitrary, considering containers are largely successful because they help bridge the two,…

> Hope this makes sense and that I understood your point accurately!

I'm happy to hear all of that and, yes, I believe you did.

> Docker [...] is singularly focused on the development experience, i.e. the inner loop of code/test/build, not the outer loop of deploying to production (which is largely controlled by cloud platforms and k8s at this point).

I would push back on this a bit: although it may not be a focus, and that's totally fair, deployment is undeniably part of the developer experience, particularly within the context that containers were born into (i.e. DevOps values of continuous deployment & no silos). I certainly wouldn't presume to tell you what to do, but I would suggest that Docker is uniquely situated to address developer experience from end to end.

> We will happily work with anyone interested in working with us to improve the production/deployment landscape for Wasm

If you gave us a path out of containers for the end-to-end developer experience, I believe many of us would be eternally grateful. Let me know how I can help.

Re: The Docker+WASM Technical Preview

#63

Post by saidinesh5 »

qbasic_forever wrote: post #53
mikesir87 wrote: post #31

Earlier quoted context omitted.

Great question! The promise (and excitement) of Wasm is to have portable, secure, quick-to-start, and low resource usage apps. So, write code in Go, Rust, C++, or any other language that can output to Wasm (up to over 40 now!) and you're good to go! The binaries are super small too. Happy to dive in more too!

Why not run that go/rust/etc code natively on the machine though? Is there extra sandboxing, network/filesystem virtualization or anything gained by compiling to and running in a WASM environment?

Gained by you running your app on your own server? not much really. Gained by some "serverless" provider who tries to run multiple apps like yours, in parallel on the same machine? Yes. Less process overhead. Probably, less memory footprint too.

Re: The Docker+WASM Technical Preview

#64

Post by postalrat »

gigel82 wrote: post #2

Insert "BUT WHY?" GIF here. Seriously, if you're in a position to be running native code in your environment why would you chose WASM? If you're building WASM for the web, is it really more expensive to build a pure native target out of the same source? Surely, performance wise you'll always be ahead going native.

So that your wasm images (or whatever they are called) can continue to run on whatever hardware cloud providers can build for as cheap as possible.

Could be x86, arm, some native wasm hardware, who knows. As long as it's cheap.

Re: The Docker+WASM Technical Preview

#65

Post by saidinesh5 »

petilon wrote: post #38
mikesir87 wrote: post #14

Earlier quoted context omitted.

Depends on which "this" you're referring to. We (Docker) are trying to make it easier for developers to use the tools and capabilities they know and love to build, share, and run Wasm applications. As far as Wasm itself, it's designed to provide a fast, lightweight, secure, and portable binary format. While it was originally designed to help bring native code to the browser, it's quickly spreading to the server side.…

I didn't get anything from that. My question was not about WASM but Docker+WASM project. Why problem does it solve?

Easy orchestration and deployment is the only thing I can think of. Because of docker's infrastructure.

But tbh if orchestration is really the concern, Docker + wasm seems less efficient than having a dedicated app that can orchestrate multiple wasm modules within the same process. But maybe that's something docker can solve later as the actual requirements emerge.

Re: The Docker+WASM Technical Preview

#66

Post by nateabele »

javaunsafe2019 wrote: post #54
nateabele wrote: post #5

Earlier quoted context omitted.

Put simply, more powerful isolation than Docker (with explicit, granular managed effects), and a simpler operating model, i.e. no container orchestration. You can actually compile modules from disparate stacks that call into one another in a single runtime.

And for just that give up all the freedom docker runtimes give us? I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve. And I don’t understand why docker is supporting this as docker + wasm makes no sense at all as wasm wants to replace docker as the runtime provider …

> And for just that give up all the freedom docker runtimes give us?

Constraints give you freedom because they allow you to make guarantees. Checksums, reliable test suites, and good software abstractions are all examples.

> I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve.

Those are runtimes, not languages. Here's a list of languages that compile to WASM: https://www.fermyon.com/wasm-languages/webassembly-language-...

IMO bash wouldn't make sense, but Java and Kotlin are there, as well as AssemblyScript, which is basically TypeScript.

Re: The Docker+WASM Technical Preview

#67

Post by stoplying1 »

timanglade wrote: post #61
lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

"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 Comp…

This seems like a good way to muddle the remaining value prop that docker has. I have zero idea why I'd want wasm via docker tooling vs what exists, especially as people more more and more to not-docker for building and running their containers. I think I see what someone is trying to do, but I don't know any dev looking for this or having a problem solved by it.

Re: The Docker+WASM Technical Preview

#68

Post by stoplying1 »

theplumber wrote: post #57
lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

I guess it's a wasm runtime. Basically a way to execute a wasm binary just like you use docker to execute a x64 binary

Except that would've been too easy to understand, and instead seems like they're using wasmedge anyway. Needlessly confusing, why do companies do this?

Re: The Docker+WASM Technical Preview

#69

Post by vlunkr »

syrusakbary wrote: post #49
_mme wrote: post #46

Earlier quoted context omitted.

I don't know Syrus nor Wasmer :) However, I'm genuinely interested - why would this make Kubernetes obsolete? If Wasm rules the future, as you believe, why shouldn't it run in a pod?

Here are some of the thoughts behind my reasoning that I posted previously in HN. Hope the are insightful! https://news.ycombinator.com/item?id=27158187 https://news.ycombinator.com/item?id=26271806

Even if you change the unit of computation in k8s from a container, that's only one problem that it solves. What about deployments, services, ingress, configmaps/secrets, jobs, volumes, etc. If you're going to create your own distributed system, all these concepts are going to exist in some form.
Post reply on HN