5 ms·

I don't think he understands what K8s is. WASM is the new Docker, but you still need something to manage/orchestrate/schedule all those WASM instances. What if

by kitd 5y ago

I don't think he understands what K8s is. WASM is the new Docker, but you still need something to manage/orchestrate/schedule all those WASM instances. What if your WASM process goes down, who will restart it? What if you need 10 extra instances to handle a traffic burst? How do you isolate associated WASM instances from the rest of the environment, and manage their access to/from the outside world? How do you provide them with configuration or credentials? You still need something like K8s, even if you're not using docker underneath . Indeed you can already use other runtimes under K8s, so what he is proposing is nothing new anyway.

Hokusai 5y ago
> I don't think he understands what K8s is. WASM is the new Docker Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it.
- brabel 5y ago
  > Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it. Before containers became a thing, everyone was happily deploying their Java applications on Java application containers (Tomcat, Weblogic, those things, remember?)... so I wouldn't say it has nothing to do with Kubernetes... just wait a bit and you might as well see the new generation of Weblogic written on WASM.
x3ro 5y ago
You mean like the author says, at the end of the article: > I compare WebAssembly to K8s, but really it's more like processes and private namespaces. So one answer to the question as initially posed is that no, WebAssembly is not the next Kubernetes; that next thing is waiting to be built, though I know of a few organizations that have started already. > One thing does seem clear to me though: WebAssembly will be at the bottom of the new thing, Edit: formatting
- kitd 5y ago
  Yes, you're right. I missed that. A bit of a shame to leave it to the end though.
- ghostoftiber 5y ago
  Whenever anyone does that they might as well simply state "I wrote this entire article and then realized I was wrong". Writing is a thinking exercise.
  - dr_hooo 5y ago
    Sounds more like clickbait an some [0] [0]https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines?wprov=sfla1 https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
- almostdeadguy 5y ago
  But to the point that K8s has "nothing a priori to do with containers" made by a sibling comment to yours, there's no reason for WASM to necessitate "the next Kubernetes". WASM is just a different workload type that could be orchestrated w/ Kubernetes. I haven't looked too much into it, but I assume that's what projects like Krustlet are working on: https://krustlet.dev/ https://krustlet.dev/ I think that's kind of essential to understanding the role Kubernetes fulfills: it's an automation platform.
lewisjoe 5y ago
You are right, and wrong. Yes we will need a kubernetes-like orchestrator to manage WASM instances. But what the author means in general is that WASM will change the game entirely, such that the industry's recent affair with Kubernetes will become irrelevant. And I agree.
- manmal 5y ago
  I don’t see how. Everything K8s does will still be needed. Switching from containers to lightweight VMs is not that big a step. Distribution becomes easier, but what really changes apart from that?
kortex 5y ago
Yeah, I'm not seeing it, either. Kubernetes' scope is right in the name: control loops. K8s is basically a super powerful IFTTT engine: it looks at state, looks at spec, and figures out how to jigger the system until state matches spec. It has nothing a priori to do with containers, it just happened to be written in service of that space. You could use k8s to run your teakettle. It's like saying QEMU is the new Systemd; it doesn't even make sense, it's a category error.
keymone 5y ago
that is my impression too and i've honestly forced myself to mentally take a few steps back and consider that maybe i got something wrong / misinterpreted.
cpuguy83 5y ago
Wasm is a compile target. You can use tools like wasmtime to handle isolation and linking in wasi (the system interface). In that sense, wasmtime is an alternative to runc for wasm/wasi. In no way is any of this a replacement for a high level tool like docker.

by kitd 5y ago

Hokusai 5y ago

> I don't think he understands what K8s is. WASM is the new Docker Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it.

brabel 5y ago
> Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it. Before containers became a thing, everyone was happily deploying their Java applications on Java application containers (Tomcat, Weblogic, those things, remember?)... so I wouldn't say it has nothing to do with Kubernetes... just wait a bit and you might as well see the new generation of Weblogic written on WASM.

x3ro 5y ago

You mean like the author says, at the end of the article: > I compare WebAssembly to K8s, but really it's more like processes and private namespaces. So one answer to the question as initially posed is that no, WebAssembly is not the next Kubernetes; that next thing is waiting to be built, though I know of a few organizations that have started already. > One thing does seem clear to me though: WebAssembly will be at the bottom of the new thing, Edit: formatting

kitd 5y ago
Yes, you're right. I missed that. A bit of a shame to leave it to the end though.
ghostoftiber 5y ago
Whenever anyone does that they might as well simply state "I wrote this entire article and then realized I was wrong". Writing is a thinking exercise.
- dr_hooo 5y ago
  Sounds more like clickbait an some [0] [0]https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines?wprov=sfla1 https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
almostdeadguy 5y ago
But to the point that K8s has "nothing a priori to do with containers" made by a sibling comment to yours, there's no reason for WASM to necessitate "the next Kubernetes". WASM is just a different workload type that could be orchestrated w/ Kubernetes. I haven't looked too much into it, but I assume that's what projects like Krustlet are working on: https://krustlet.dev/ https://krustlet.dev/ I think that's kind of essential to understanding the role Kubernetes fulfills: it's an automation platform.

lewisjoe 5y ago

You are right, and wrong. Yes we will need a kubernetes-like orchestrator to manage WASM instances. But what the author means in general is that WASM will change the game entirely, such that the industry's recent affair with Kubernetes will become irrelevant. And I agree.

manmal 5y ago
I don’t see how. Everything K8s does will still be needed. Switching from containers to lightweight VMs is not that big a step. Distribution becomes easier, but what really changes apart from that?

kortex 5y ago

Yeah, I'm not seeing it, either. Kubernetes' scope is right in the name: control loops. K8s is basically a super powerful IFTTT engine: it looks at state, looks at spec, and figures out how to jigger the system until state matches spec. It has nothing a priori to do with containers, it just happened to be written in service of that space. You could use k8s to run your teakettle. It's like saying QEMU is the new Systemd; it doesn't even make sense, it's a category error.

keymone 5y ago

that is my impression too and i've honestly forced myself to mentally take a few steps back and consider that maybe i got something wrong / misinterpreted.

cpuguy83 5y ago

Wasm is a compile target. You can use tools like wasmtime to handle isolation and linking in wasi (the system interface). In that sense, wasmtime is an alternative to runc for wasm/wasi. In no way is any of this a replacement for a high level tool like docker.