5 ms·

> 1 tight security model > 2 very fast boot-up time > 3 scalability at the edge > 4 much smaller footprints > 5 portability across environments Aren't #2-4

> 1 tight security model > 2 very fast boot-up time > 3 scalability at the edge > 4 much smaller footprints > 5 portability across environments Aren't #2-4, just wasm rediscovering static linking? 95% of the advantage that docker has over a tarball is due to gcc's (and glibc's) strong bias towards dynamic linking and how hard it is to portably package a python application's dependencies.

recursive 3y ago
Perhaps not coincidentally, #1 and #5 seem like the most significant features from this list.
throwway120385 3y ago
Another often-overlooked advantage of Docker is the fact that its checksummed tarball of your base container image can be shared with other container images. This can cut down on data transfer and data size if you use the same base image for everything because it's only transferring delta images.
- hinkley 3y ago
  Most of our services use the same base image and some of them run in the same host. The main thing to watch out for is that the steady state disk usage is different from the worst case. During upgrades the amount of disk used can balloon up for a little while, and these sorts of transient costs tend to mess with people’s ability to do capacity planning properly. So there’s a law of diminishing returns for pushing things out of your images into a common base. The more you do the larger the over/under gets. Spend a good bit of energy in shrinking the base image, not just growing it, and you’ll be okay.
- strangescript 3y ago
  This doesn't even really apply to wasm though. That is the big difference. You would have a runtime that can execute wasm, and its all the same. Any browser can run wasm provided you don't try unsupported sys-calls.
  - throwway120385 3y ago
    The point I'm trying to make is that what is being described as a "revolutionary" approach -- that of putting all of your application code into a single binary -- is just static linking but using wasm plus a small JavaScript engine. It's revolutionary if your whole experience is with Node.JS inside of Docker, but from my perspective it's the rediscovery of a 50 year old technology. Just with TypeScript/JavaScript in a browser engine. To be clear this is a great idea and will solve a lot of problems, but it's not like people haven't thought of this before today.
cmgbhm 3y ago
I think of the Pro-WASM argument as trying to tightly define stricter runtime capabilities model and static linking bare container style. N wasm operations to guard rather than N syscalls. The cloudflare worker infrastructure is very cost effective. The thing that I wonder about portability is side channel defense mechanism responsibility.
- mike_hearn 3y ago
  On Linux you can block off syscalls by number these days. If you only want to expose read and write on some pre-prepared file descriptors you can do that. This leads to the question of what security is being added by the bytecode layer. You could argue that you're insulated from CPU errata, but cloud and hosting vendors have been selling raw CPU access for decades without real issue beyond side channel attacks (patched, also affects you even with WASM). WASM came out of the web and is needed/wanted by the web folks because they can't rely entirely on operating system kernel sandboxing (Windows is dubious, macOS is powerful but private/undocumented API), and because they don't like the idea of implicitly incorporating every possible device's CPU ISA into the HTML5 spec. Neither issue applies on Linux servers where nothing is a formal spec anyway and the Linux sandboxing facilities are powerful and open. JIT/interpretation can only slow things down over using native code, so "fast startup" is probably being confounded by the fact that WASM programs tend to be written in C++ or Rust.
sidewndr46 3y ago
and #5 is just rediscovering the JVM
- aidenn0 3y ago
  Or the Z-machine[1] 1: https://en.wikipedia.org/wiki/Z-machine https://en.wikipedia.org/wiki/Z-machine
- recursive 3y ago
  Partly, but the capabilities exposed by WASM are different. JVM is fundamentally classic-OOP. And you might have reason to trust WASM bytecode as a standard more than JVM bytecode.
saidinesh5 3y ago
I think 2 is more about how a single wasm interpreter can host multiple "serverless applications" and execute them without the process (/language runtime) spawning overhead. > 95% of the advantage that docker has over a tarball is due to gcc's (and glibc's) strong bias towards dynamic linking and how hard it is to portably package a python application's dependencies. Mhm. docker, flatpak, snap, appimages .. so much complexity is basically us dealing with linux dll hell imo.

recursive 3y ago

Perhaps not coincidentally, #1 and #5 seem like the most significant features from this list.

throwway120385 3y ago

Another often-overlooked advantage of Docker is the fact that its checksummed tarball of your base container image can be shared with other container images. This can cut down on data transfer and data size if you use the same base image for everything because it's only transferring delta images.

hinkley 3y ago
Most of our services use the same base image and some of them run in the same host. The main thing to watch out for is that the steady state disk usage is different from the worst case. During upgrades the amount of disk used can balloon up for a little while, and these sorts of transient costs tend to mess with people’s ability to do capacity planning properly. So there’s a law of diminishing returns for pushing things out of your images into a common base. The more you do the larger the over/under gets. Spend a good bit of energy in shrinking the base image, not just growing it, and you’ll be okay.
strangescript 3y ago
This doesn't even really apply to wasm though. That is the big difference. You would have a runtime that can execute wasm, and its all the same. Any browser can run wasm provided you don't try unsupported sys-calls.
- throwway120385 3y ago
  The point I'm trying to make is that what is being described as a "revolutionary" approach -- that of putting all of your application code into a single binary -- is just static linking but using wasm plus a small JavaScript engine. It's revolutionary if your whole experience is with Node.JS inside of Docker, but from my perspective it's the rediscovery of a 50 year old technology. Just with TypeScript/JavaScript in a browser engine. To be clear this is a great idea and will solve a lot of problems, but it's not like people haven't thought of this before today.

cmgbhm 3y ago

I think of the Pro-WASM argument as trying to tightly define stricter runtime capabilities model and static linking bare container style. N wasm operations to guard rather than N syscalls. The cloudflare worker infrastructure is very cost effective. The thing that I wonder about portability is side channel defense mechanism responsibility.

mike_hearn 3y ago
On Linux you can block off syscalls by number these days. If you only want to expose read and write on some pre-prepared file descriptors you can do that. This leads to the question of what security is being added by the bytecode layer. You could argue that you're insulated from CPU errata, but cloud and hosting vendors have been selling raw CPU access for decades without real issue beyond side channel attacks (patched, also affects you even with WASM). WASM came out of the web and is needed/wanted by the web folks because they can't rely entirely on operating system kernel sandboxing (Windows is dubious, macOS is powerful but private/undocumented API), and because they don't like the idea of implicitly incorporating every possible device's CPU ISA into the HTML5 spec. Neither issue applies on Linux servers where nothing is a formal spec anyway and the Linux sandboxing facilities are powerful and open. JIT/interpretation can only slow things down over using native code, so "fast startup" is probably being confounded by the fact that WASM programs tend to be written in C++ or Rust.

sidewndr46 3y ago

and #5 is just rediscovering the JVM

aidenn0 3y ago
Or the Z-machine[1] 1: https://en.wikipedia.org/wiki/Z-machine https://en.wikipedia.org/wiki/Z-machine
recursive 3y ago
Partly, but the capabilities exposed by WASM are different. JVM is fundamentally classic-OOP. And you might have reason to trust WASM bytecode as a standard more than JVM bytecode.

saidinesh5 3y ago

I think 2 is more about how a single wasm interpreter can host multiple "serverless applications" and execute them without the process (/language runtime) spawning overhead. > 95% of the advantage that docker has over a tarball is due to gcc's (and glibc's) strong bias towards dynamic linking and how hard it is to portably package a python application's dependencies. Mhm. docker, flatpak, snap, appimages .. so much complexity is basically us dealing with linux dll hell imo.