Hacker News Reader

Comment by lolinder | Hacker News Reader

> Containers feel like a clever hack to get existing apps packaged up and reduce the overhead of VMs

That's because that's exactly what they are, and that's why this claim is weird. Containers do not solve the same problem as WASM. No one is going to be taking Postgres and compiling it to WASM. They're not going to do that for redis or memcached or any of the other innumerable services that live happily inside of a container and need low-level access to a Unix system.

We may very well find that WASM replaces containers as to go to for bundling a typical web app, especially one built with a compiled language rather than one that already has a runtime. But we will still use containers for the things that containers are good at.

View on HN

I'd argue containers aren't that good at databases or caches (production ones anyway, fine for development) and containers are specifically targeted at app deployments.

Containers just add overhead for stuff like memcached and complicate database management.

That's a reasonable argument to make (although I think it depends on the context), but I see no reason to believe WASM would be any better. And the fact remains that a lot of people do use containers quite successfully for these things. I don't believe those same people would turn to WASM.

Someone already did: https://news.ycombinator.com/item?id=32498435

Overall the timeline doesn't seem implausible to me.

Okay, I'll amend my statement: no one should be using a WASM-powered Postgres as their production DB.

Right now compiling to WASM is sort of the equivalent of "but will it run Doom?" People are doing it for everything, and it's a fun experiment to stretch WASM. I could see it being useful in making some things available in the browser that otherwise couldn't be. But that doesn't mean it's going to replace containers in their rightful place. It'll be another option, and unless you're trying to solve one of the few problems that WASM was designed to solve (like running in the browser), it will be the wrong one.

> Okay, I'll amend my statement: no one should be using a WASM-powered Postgres as their production DB.

Realistically containers neither. DBs are infrastructure best left to PaaS or dedicated VMs you can provision/manage better.

Why won't they do these things? At the very least, you will only need to provide one binary, rather than one per architecture.

Because the burden of compiling a binary per architecture is microscopic when you're dealing with something like postgres or redis or memcached. Someone sets up a CI pipeline that compiles binaries for the supported platforms. The pipeline produces the required binaries with each release.

These projects care far more about performance than they do about ease of compilation or even of installation, because they're compiled once and run trillions of times in performance sensitive contexts. As I noted in reply to a sibling, I could see it being useful to run in a browser as a sort of learning playground, but that is not how people are going to deal with their production DBs—the bottleneck represented by WASI is not going to be worth it.

Reply on news.ycombinator.com