"In the year 2030, no one will remember Kubernetes." I feel like this prolog missed an important point. Kubernetes abstracts data centers: networking, storage, workload, policy. Containers implement workloads. They're at different layers. And back to the article's point: WASM may well replace containerized workloads, indeed there are already WASM node runtimes for Kubernetes. Something else may well replace Kubernete…
WASM will replace containers
81–90 of 371 posts
Re: WASM will replace containers
#82I'm always reminded of Gary Bernhardt's "the birth and death of javascript" when wasm gets discussed. While it's a bit tongue-in-cheek, I think it really drives home that it's really just another layer of abstraction that may or may not be useful for a given problem, and might not be the silver bullet that anyone is looking for. I recon that whether or not wasm will take over everything will mostly be about trade off…
Re: WASM will replace containers
#83> In the year 2030, no one will remember Kubernetes.
So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
> The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals.
Here is why we ended up here: In my experience, developers want to write code and ship features to hit their quarterly goals.
Sure, and my angry PlatformOps (formerly DevOps (formerly SRE (formerly Ops))) is stuck picking up the pieces because we are getting crap while we desperately paging you because we have no clue what "duplicate street key" in your logs mean. On top of that, InfoSec dropped us 10 tickets about code level library vulnerabilities in your docker container but all the Developer's Managers got together to convince them it was our problem somehow.
So we are forced to write this bundle of terribly written Ops type software in attempt to keep this train on the tracks while you strap rockets to cafe car.
WASM replacing containers is just a solution looking for a problem. Containers solved a problem of "How do we run two different versions of PHP on a single server without them colliding." Most of the containers problem is higher level DevOps problems that we haven't been able to solve and WASM isn't going to change that. I deal with a team that writes 100% Golang so their code is like WASM as it's ship binary and done. Yea, they begged for Kubernetes because it works a ton better then custom Ansible they wrote to keep these VMs/Load Balancer in sync.
Re: WASM will replace containers
#84It would be so great if WASM gives us the paradise that Java promised thirty years ago. Being able to get fast, "write once, run anywhere" would be awesome. I wonder if someone could make a decent cross-platform GUI toolkit to save us from the horribly slow Electron-hell we've carved out for ourselves.
We could name it the Abstract Window Toolkit and it would render the same on every platform. But then, someone would get butthurt about it having a "distinct look" and decide to make the Standard Widget Toolkit that uses native bindings. Fantastic that it stops that distinct look, with the small asterisk that you now have to ship .dll/.so/.dylib shims in your "cross platform" app I'm no wasm expert, but I find it jus…
Probably not, but that's sort of orthogonal to my point.
Java started as "write once run anywhere", but it has almost become the opposite of that: "write once, run it on your specific server".
"Portability" is not nearly the same concern with Java as it was thirty years ago; I don't have direct numbers on this, but I would guess that a vast majority of Java code written in 2025 is either running on a server or running an Android app, neither of which are nearly as "portable" what was kind of promised in the 90's, at least not on the desktop.
Re: WASM will replace containers
#85There's not even a single argument in there to support the clickbait title. We have containers, but "containers are annoying". WASM won't be annoying? Pray tell, how do you surmise that?
Docker too complicated? Build times too long? You believe WASM tools will be simpler and faster... why?
Re: WASM will replace containers
#86Re: WASM will replace containers
#87When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm. To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it…
Re: WASM will replace containers
#88Re: WASM will replace containers
#89"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…
>But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. So an operating system?
I hope for a much more near term bright future for WASM: language interop. The lowest common denominator today is C, and doing FFI manually is stone age. If you can leverage WASM for the FFI boundary, perhaps we can build cross language applications that can enjoy the strengths of all libraries, not just those outside of our language silos.
Re: WASM will replace containers
#90That's 5 years from now.
Which is a pretty good time frame for getting enterprisey things on to kubernetes.
And maybe a bit short for getting vendors to add a new sandboxed VM type to their supported platforms.