If you are going to recompile everything statically into a new target, why don't just build an αpε? It seems like a more elegant and clean solution.
WebAssembly: Docker Without Containers
211–220 of 313 posts
Re: WebAssembly: Docker Without Containers
#212Earlier quoted context omitted.
> Fast - it can offer native-like speed via the JIT/AOT capabilities of most runtimes. No cold starts, unlike booting a VM or starting a container. What do you mean? This bullet point had a rocket emoji! Surely you don't actually want evidence to support a rocket emoji?!?
I don’t know about the rest of you but I’m pretty sure rockets are a couple of magnitudes faster then blue whales. Q.E.D. #
... rocket-propelled blue whales? (I mean, if we have sharks with lasers...)
Re: WebAssembly: Docker Without Containers
#213Earlier quoted context omitted.
So fundamental that those tools don't exist at all.
Hey, so I thought I remembered your username. This isn’t the first interaction we’ve had, or I’ve seen you have, that follows this similar pattern. In fact it’s the third example from you under this post! It’s not a particularly pleasant experience to discuss anything with you, as after you make a particularly vapid comment that is naturally rebuffed you seem to just try to make snarky replies rather than engage. Ple…
Well, I learned about the InteliJ plugin, I guess.
Which I don't use hence why I wasn't aware of it.
Re: WebAssembly: Docker Without Containers
#214Earlier quoted context omitted.
Hey, so I thought I remembered your username. This isn’t the first interaction we’ve had, or I’ve seen you have, that follows this similar pattern. In fact it’s the third example from you under this post! It’s not a particularly pleasant experience to discuss anything with you, as after you make a particularly vapid comment that is naturally rebuffed you seem to just try to make snarky replies rather than engage. Ple…
Well, I learned about the InteliJ plugin, I guess. Which I don't use hence why I wasn't aware of it.
Yes, your lack of knowledge was never in question.
> The Dunning–Kruger effect is a cognitive bias whereby people with low ability, expertise, or experience regarding a certain type of task or area of knowledge tend to overestimate their ability or knowledge
https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...
Re: WebAssembly: Docker Without Containers
#215Earlier quoted context omitted.
No cold-starts means no overhead of starting a process to answer a request like most container-based serverless environments (without having to keep pre-warmed instances which kind of defeats the purpose) A couple references regarding cold-starts and performance in serverless environments. https://www.fastly.com/blog/lucet-performance-and-lifecycle https://arxiv.org/abs/2010.07115
Are we so what's-old-is-new-again as to be re-inventing fast-cgi at this point? And why are we pretending this has anything to do with WASM instead of just how your API/service is designed?
That’s basically the history of computing! There are some intrinsic advantages to using Wasm vs VMs or containers for certain scenarios, like serverless. That’s very similar to what’s going on with cloudflare workers and V8 isolates. It’s not one size fits all by any means, but it is certainly really good for many scenarios where containers are not
Re: WebAssembly: Docker Without Containers
#216If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Solomon Hykes (co-founder of Docker) https://twitter.com/solomonstre/status/1111004913222324225
This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…
the crucial value proposition of Docker was to show megacap cloud providers that containers are a thing for developers and to build them first class into their cloud platforms -> kubernetes. I went to a GCP conference shortly after Docker went big and everyone was talking about it. It was no surprise that Google mentioned the word "container" 100s of times throughout the full day conference and never mentioned the name Docker once.
Re: WebAssembly: Docker Without Containers
#217AWS Lambda SnapStart makes all these alternative, constrained serverless systems look pretty painful for little gain.
Re: WebAssembly: Docker Without Containers
#218Earlier quoted context omitted.
> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.
This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html
That's not really threading by the definition normally used in other languages. You can't allocate JS objects or structures and read/write them from multiple threads at once. JS is an inherently thread unsafe language and likely always will be.
Re: WebAssembly: Docker Without Containers
#219Earlier quoted context omitted.
> Docker's value proposition is emphatically not security [...] It's the ability to deploy [...] gnarly and imperfect software This sounds like a recipe for disaster to me and is why I haven't gotten into Docker. If the software being deployed is too complicated to build and install without Docker, but Docker doesn't provide secure isolation, how can you be sure that this "gnarly and imperfect" mess of a system is se…
> how can you be sure that this "gnarly and imperfect" mess of a system is secure? You can't. But it's not like escaping a container is going to happen because of a simple bug. You need an exploitable vulnerability in the containerized app that creates a path to escaping the container. But yeah, if you want to isolate an app for security reasons, then you need a VM.
Right, but if Docker allows us to package much more complicated applications (as opposed to being forced to simplify) that gives the bugs more room to hide and increases the risk of unforeseen interactions resulting in security bugs in the application.
So what I'm trying to say is that making complicated applications easier to deploy doesn't seem like a win unless you also mitigate the increased security risk that comes with more complicated applications.
Re: WebAssembly: Docker Without Containers
#220Earlier quoted context omitted.
No cold-starts means no overhead of starting a process to answer a request like most container-based serverless environments (without having to keep pre-warmed instances which kind of defeats the purpose) A couple references regarding cold-starts and performance in serverless environments. https://www.fastly.com/blog/lucet-performance-and-lifecycle https://arxiv.org/abs/2010.07115
Are we so what's-old-is-new-again as to be re-inventing fast-cgi at this point? And why are we pretending this has anything to do with WASM instead of just how your API/service is designed?
FastCGI reuses the same process for multiple requests. As I understand it wasmtime now supports very fast startup so you can use a new instance per request (avoiding the risk of inter-request bugs) with very low overhead (5 microseconds on their benchmark https://bytecodealliance.org/articles/wasmtime-10-performanc....)
With Firecracker I believe snapshot restore time is around 2-3ms. In my tests wasmtime ran about 50% the speed of native so depending on your workload it might still be faster for short running jobs where the startup time dominates. (Wasmer was maybe 80-90% of native speed but I don't know their startup times.)