6 ms·

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

> 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-service-application-with-wasm https://docs.docker.com/desktop/wasm/#running-a-multi-servic...

corysama 4y ago
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 fulfills very nicely. It cannot, for example, take my dog for a walk. So, it can’t do “anything” ;p It’s hard to get out of that head-space because you’ve been so deep in it for so so long. But, I and 85% of people here have no idea what narrow set of goals Docker+Wasm fulfills. Something about apps and security something something. Mostly for servers probably. Some awesome-fit exemplar use cases would help a lot.
- dmingod666 4y ago
  I am trying to head around this. what are the limitations of this? ok, for example can you deploy postgres on the browser with this? can you have a full OS container running on the browser with this, say ubuntu shell frontend with some javascript and an ubuntu container running on the browser? The first impression from 'Docker + WASM' surely sounds like that is what it is, but after about 30 mins, I am not so sure that is actually the case.
- deleted 4y ago
  [deleted]
- bradgessler 4y ago
  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"?
  - timanglade 4y 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-lambda-deployments-using-oci-container-images/ https://aws.amazon.com/blogs/containers/containerizing-lambd...
    - bradgessler 4y ago
      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?"
dleslie 4y ago
So if I understand you correctly, you want Docker to be a trusted host for wasm binaries as well as container images? Where the tooling you've made is intended to aid users along this path. It sounds like you're anticipating a new market segment for artifact deployment and want to be its primary service provider.
- deleted 4y ago
  [deleted]
xeonmc 4y ago
So putting it simply, it’s wasmtime with a “wasm-hub”, stapled onto docker? And I guess dockerfile can serve as a wasm-playlist for stuffing a whole bunch of them in one container? Call it wasm-spotify
emptysongglass 4y ago
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 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 approach.
- deleted 4y ago
  [deleted]

corysama 4y ago

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 fulfills very nicely. It cannot, for example, take my dog for a walk. So, it can’t do “anything” ;p It’s hard to get out of that head-space because you’ve been so deep in it for so so long. But, I and 85% of people here have no idea what narrow set of goals Docker+Wasm fulfills. Something about apps and security something something. Mostly for servers probably. Some awesome-fit exemplar use cases would help a lot.

dmingod666 4y ago
I am trying to head around this. what are the limitations of this? ok, for example can you deploy postgres on the browser with this? can you have a full OS container running on the browser with this, say ubuntu shell frontend with some javascript and an ubuntu container running on the browser? The first impression from 'Docker + WASM' surely sounds like that is what it is, but after about 30 mins, I am not so sure that is actually the case.
deleted 4y ago
[deleted]
bradgessler 4y ago
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"?
- timanglade 4y 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-lambda-deployments-using-oci-container-images/ https://aws.amazon.com/blogs/containers/containerizing-lambd...
  - bradgessler 4y ago
    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?"

dleslie 4y ago

So if I understand you correctly, you want Docker to be a trusted host for wasm binaries as well as container images? Where the tooling you've made is intended to aid users along this path. It sounds like you're anticipating a new market segment for artifact deployment and want to be its primary service provider.

deleted 4y ago
[deleted]

xeonmc 4y ago

So putting it simply, it’s wasmtime with a “wasm-hub”, stapled onto docker? And I guess dockerfile can serve as a wasm-playlist for stuffing a whole bunch of them in one container? Call it wasm-spotify

emptysongglass 4y ago

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

deleted 4y ago
[deleted]