8 ms·

This is great news. I'm really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs. While the gener

This is great news. I'm really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs. While the general trend today is to back the serverless environment with Javascript runtimes (Cloudflare runs its edge on top of V8, Netlify uses deno, most other serverless runtimes use nodejs), I'm optimistic that WebAssembly will take over this space eventually, for a bunch of reasons like: 1. Running a WASM engine on the cloud means, running user code with all security controls, but with a fraction of the overhead of a container or nodejs environment. Even the existing Javascript runtimes, comes with WebAssembly execution support out of the box! which means these companies can launch support for WASM with minimal infra changes. 2.It unlocks the possibility of running a wide range of languages. So there’s no lock-in with the language that the Serverless provider mandates. 3.Web pages that are as ancient as the early 90s are perfectly rendered even today in the most modern browsers because the group behind the web standards strive for backward compatibility. WebAssembly’s specifications are driven by those same folks - which means WASM is the ultimate format for any form of code to exist. Basically, it means a WASM binary is future proof by default. I've published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique, here - https://writer.zohopublic.com/writer/published/nqy9o87cf7aa789ba49419eac167d0c34cfcb https://writer.zohopublic.com/writer/published/nqy9o87cf7aa7...

electroly 5y ago
> a fraction of the overhead of a container I mean, only in theory or when looking at it from the right angle, right? Or are you only comparing against JavaScript (unclear)? WASM is still much slower than native code. Containers spend most of their time executing native code; the "overhead" of containers is at the boundaries and is minor compared to the slowdown by moving from native code to WASM. In the future WASM may approach native performance, but it's not there now. I'm 100% certain that transitioning my native-code-in-containers workloads to WASM would be slower, not faster.
- teleclimber 5y ago
  Edge functions are typically run intermittently, with their runtime stopped to free up resources between runs. Therefore a big factor is startup and shutdown speed. Containers are pretty bad there. Deno is better, and WASM is unbeatable, especially with things like Wizer[0]. [0]https://github.com/bytecodealliance/wizer https://github.com/bytecodealliance/wizer
  - lucacasonato 5y ago
    Deno can in theory do the pre-initialization that wizer does for JS too. We have all of the infrastructure for it, we just have not gotten around to actually implementing it yet.
    - teleclimber 5y ago
      Issue 3335. I know. I'm watching it. :))
  - electroly 5y ago
    Makes sense when talking about edge functions, but then OP started talking about Kubernetes. Our Kubernetes workloads don't resemble that at all; there's virtually none of that container startup/shutdown overhead to be concerned about. Most weeks, no containers are started or stopped at all.
olah_1 5y ago
I agree about WASM. I am sort of worried that Deno may be too late tbh. Why would I bother with an interpreted language at all when I can code in any language I want and run it anywhere with WASM?
- deleted 5y ago
  [deleted]
- paulgb 5y ago
  WASM still needs an interface layer to interact with the outside world (filesystem, etc.) My money is on WASI, but Deno becoming the interface layer has some advantages, mainly that most WASM-supporting languages already have tooling around JavaScript ffi.
- teleclimber 5y ago
  The "any language" advantage of WASM is theoretical. Each language is at a different level of support of WASM, libraries aren't all caught up and at the same point for all languages, etc... I love the promise of WASM, but every time I look at it I get lost in a sea of acronyms, and my optimistic ideas of using language X with library Y on runtime Z are dashed because there is some missing piece somewhere. If anything, the "any language" thing creates a giant matrix of potential pitfalls for the programmer. In comparison, the combination of JS/TS, the browser API and a solid std lib looks pretty good for some problems.
  - irq-1 5y ago
    Agreed. There is also the lack of a GC in WASM and Denos' use of existing web standard APIs.
- jrockway 5y ago
  What is "any language" these days? I feel like WebAssembly's day will come when one of those is Javascript, and so far that hasn't happened. Go's support is pretty good (with tinygo offering a tiny runtime more suited to this application). Rust appears to support compiling directly to WebAssembly, and there are some smaller languages like AssemblyScript and Lua with support. I'm guessing plain C works fine. Then there are projects that compile the runtime for interpreted languages to WebAssembly, so you can theoretically run things like Python. Nobody is writing applications in C or AssemblyScript, so that leaves rust or go. If you're using one of those languages, though, you can just (cross-)compile a binary and copy it to a VM that is on some cloud provider's free tier, so this isn't really easing any deployment woes. It was already as easy with native code, so WebAssembly isn't adding much stuff here. (The isolation aspect was interesting in the days before Firecracker, but now every computer has hardware virtualization extensions and so you can safely run untrusted native code in a VM at native speeds.) Anyway, I always wanted WebAssembly for two things: 1) To compile my React apps to a single binary. 2) To use as a plugin system for third-party apps (so I don't have to recompile Nginx to have OpenTracing support, for example). The language support hasn't really enabled either, so I'm a little disappointed. (Disappointed isn't really fair. I've invested no effort in this, and I can't be disappointed that someone didn't make a really complicated thing for me for free. But you know what I mean.)
syrusakbary 5y ago
I fully agree with your take. I think JS-directed computation is very good towards short-term adoption (since running JS on the Edge is probably the most popular use case), but eventually the needs to run other programming languages at the Edge will likely eclipse the JS use case. At Wasmer [1] we have been working actively towards this future. Lately more companies have been also doing awesome work on these fronts: Lunatic, Suborbital, Cosmonic (WasmCloud) and Fermyon (Spin). However, each of us with a different take/vision on how to approach the future of Computation at the Edge. I'm very excited about to see what each approach will bring into the table. [1] https://wasmer.io/ https://wasmer.io/
dmitriid 5y ago
> mainly as a weapon against rising cloud deployment costs. Cloud Functions is literally code you're running in the cloud. And the moment you approach their limit(ation)s, you will see the same "rising cloud deployment costs" > Running a WASM engine on the cloud means ... a fraction of the overhead of a container or nodejs environment You do realise that there are other languages than javascript in nodejs? That there other environments than cloud functions? And that you can skip that overhead entirely by running with a different language in a different environment? Or even run Rust in AWS Lambda if you so wish? > so there’s no lock-in with the language that the Serverless provider mandates. And at the same time you're advertising for a runtime lock in. This doesn't compute. > Web pages that are as ancient as the early 90s are perfectly rendered even today... Basically, it means a WASM binary is future proof by default. It's not future proof. Web Pages from the 90s are not actually rendered perfectly today because browsers didn't agree on a standard rendering until late 2000s, and many web pages from the 90s and 2000s were targeting a specific browser's feature set and rendering quirks. Web Pages from the 90s are rendered good enough (and they had few things to render to begin with). As web's standards approach runaway asymptotical complexity, their "future-proofness" is also also questionable. Chrome broke audio [1], browsers are planning to remove alert/confirm/prompt [2], some specs are deprecated after barely seeing the light of day [3], some specs are just shitty and require backtracking or multiple additional specs on top to fix the most glaring holes, etc. > I've published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique "Let's replace somewhat unlimited code with severely limited, resource constrained code running in a slow VM in a shared instance" is not a good take. [1] https://www.usgamer.net/articles/google-chromes-latest-update-broke-a-bunch-of-browser-games https://www.usgamer.net/articles/google-chromes-latest-updat... [2] https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d [3] https://chromestatus.com/feature/4642138092470272 https://chromestatus.com/feature/4642138092470272 and https://www.w3.org/TR/html-imports/ https://www.w3.org/TR/html-imports/
- atoav 5y ago
  I sought to unserstand "serverless" but every deployment diagram I have ever seen show things that look an aweful lot like they run on... servers? Maybe I don't get the idea (and honestly I was too lazy to put in the legwork), but when I hear something like "serverless" I imagine some p2p javascript federated decentralized beast where the shared state is stored through magic and tricks with the users clients and there is literally no server anywhere to be found. Instead it seems like a buzzword (?) for a weirdly niche way of running things that someone with a 4 Euro/Month nginx instance that hosts 10 websites will probably never understand. Maybe I also don't need to understand because I know how to leverage static content, caching, fast Rust reverse proxy services and client side javascript to develope fast web stuff that gets the job done).
me_me_mu_mu 5y ago
Really, really dumb question. I've seen a lot of node/python/etc serverless offerings. Is there something where you just provide a binary and its executed each time? For example, I write a simple single responsibility piece of code in Go `add_to_cart.go` and build it, deploy it, and somehow map it to some network request. dot slash pass args, and return the result? No need to have containers or runtime?
- kasey_junk 5y ago
  AWS lambda’s work that way.
- pid-1 5y ago
  That's how every FaaS (Function as a Service) offering works. A caveat is that most non trivial applications need something more than running a function. You might need secrets management, ephemeral and non ephemeral storage, relational databases, non relational databases, dependency management, AAA capabilities, observability, queues/async, caching, custom domains... That's where said offerings differ. EDIT: actually most FaaS offerings take code as input, not binaries. I'm not sure if that was the relevant part of your question. If it was, then yeah I don't know of such service.
- brundolf 5y ago
  It's possible you'd run into environment issues. JS or Python code (or a container) doesn't have to care as much what OS or architecture it's run on. A raw binary could pierce that abstraction and make the service more complicated to offer.
- qbasic_forever 5y ago
  Find a cheap apache web host that allows cgi-bin.
- nl 5y ago
  You can do that on Lambda: https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.html https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.... AWS still needs the container/runtime to stop your code getting access to other things on the same physical computer.
api 5y ago
> I'm really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs. How would that work? Don't these tend to facilitate cloud lock-in or at least be cloud-only in the sense that they make it hard to operate your own metal infrastructure?
- deleted 5y ago
  [deleted]
- kvz 5y ago
  There is KNative for that. But really folks are using serverless to _not_ have to operate their own iron and save themselves an ops team.
  - api 5y ago
    Sure. Just saying those savings only work if the cloud vendors are in fact charging reasonable rates on serverless compute, storage, and bandwidth. In my experience cloud vendors love to tow that line but if you do the math the savings over DIY are sometimes questionable. It depends on your work load.
adam_arthur 5y ago
Also a common spec for serverless is badly needed. Serverless code should be portable between different cloud providers, otherwise there's vendor lock in and much greater opportunity to price gouge. Anybody know if a common API for serverless components is being worked on?
- gardnr 5y ago
  There's the serverless framework which is easy to use and there is terraform which is more powerful. Relevant: https://xkcd.com/927/ https://xkcd.com/927/
  - huijzer 5y ago
    It doesn’t avoid vendor lock-in. Instead of a cloud provider, it is now Terraform.
- phphphphp 5y ago
  Check out knative, it’s used for Google Cloud Run: https://knative.dev/docs/ https://knative.dev/docs/
  - algorithmmonkey 5y ago
    What is the common spec for Knative? It seems like one runs an app as normal in a container and then the special scaling sauce is handled by Knative. When I think of a portable spec for serverless, I think of something more like a Trait of an Interface that needs to be implemented, less a app hosting model. If you think about it like that, then Web Assembly component model [1] would be a great fit for defining an interface that could be implemented in a variety of languages. [1]: https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md https://github.com/WebAssembly/component-model/blob/main/des...
    - adam_arthur 5y ago
      Yes, exactly. Of course experimentation and competition is good to settle on a solid set of building blocks, but in the long run serverless code should absolutely be portable between vendors. There's a strong incentive for vendors to not allow this as it reduces their pricing power... But think we will see it eventually one way or another.
melony 5y ago
The problem is database. Distributed serverless-first SQL like spanner, Cockroach, PlanetScale are very very expensive.
- _ben_ 5y ago
  We're building PolyScale[1] to address this problem. PolyScale is a serverless edge cache for databases so you can easily distribute your reads. We are opening up early access to our connection pooling features in the next couple of weeks which allows FaaS platforms like Netlify, Cloudflare etc to create large numbers of ephemeral connections, without impacting your origin database, as well as reducing connection latency significantly. [1] https://www.polyscale.ai/ https://www.polyscale.ai/
  - tauwauwau 5y ago
    I was looking at the polyscale docs and found following PolyScale evaluates each SQL query in real-time and when it detects a DML query i.e. a SQL INSERT, UPDATE or DELETE, it extracts the associated tables for the query. Then, all data for the table(s) in question are purged from the cache, for every region globally. at https://docs.polyscale.ai/how-does-it-work/#smart-invalidation https://docs.polyscale.ai/how-does-it-work/#smart-invalidati... Isn't clearing cache for entire tables for a all DMLs which may be changing one record too intensive and how does this affect performance of cache when there are multiple DML queries being run every minute? Also can you please give the docs link to connection pooling feature
    - _ben_ 5y ago
      That’s right. Currently the auto invalidation is somewhat of a blunt instrument in that it will blow away all cache data related to the table(s) as default. That approach favors consistency over performance, but is also a natural fit to some query traffic patterns. You can also switch it off if you so desire. The next iteration that is imminent for release can be much more surgical, invalidating based on more of the query details. Connection pooling docs are coming soon as part of the feature early access launch. Feel free to drop me an email and I can let you know when its released. Im ben at our domain.
tedk-42 5y ago
Hmmm I had a look into WASM runtimes and the idea seems interesting to deploy something on a server as a lightweight execution environment (I think of Firecracker from AWS for VMs). To be honest on the server side of things containers are so nice because 99% of the time they include all your dependencies you need to run the app.
danamit 5y ago
in what world is serverless cheaper?
- kvz 5y ago
  The one where you only need a few invocations and with serverless: aren’t paying for an idling VM all of the other time. Arguably you may save yourself an ops team too.
youngtaff 5y ago
Fastly use WASM for their Edge Compute offering
yencabulator 5y ago
You can write Cloudflare Workers in WASM today. As far as I can tell from the outside, that's still "WASM-called-by-Javascript", and many of their JS optimizations don't work the same way. E.g. if a Worker calls JS `fetch` and returns that `Response`, they recognize that and remove the JS from the data path; same is not true for WASM at this time.
- kentonv 5y ago
  I think that optimization should still work when using Wasm, unless the Wasm code does something silly like manually pump the stream (read from one, write to the other), but I think you'd have to go out of your way to do that, and anyway the same is true of pure-JavaScript code.
  - yencabulator 5y ago
    Ooh, that is great news. I've been itching to write a "proxy thing" in Rust instead of JS.

electroly 5y ago

> a fraction of the overhead of a container I mean, only in theory or when looking at it from the right angle, right? Or are you only comparing against JavaScript (unclear)? WASM is still much slower than native code. Containers spend most of their time executing native code; the "overhead" of containers is at the boundaries and is minor compared to the slowdown by moving from native code to WASM. In the future WASM may approach native performance, but it's not there now. I'm 100% certain that transitioning my native-code-in-containers workloads to WASM would be slower, not faster.

teleclimber 5y ago
Edge functions are typically run intermittently, with their runtime stopped to free up resources between runs. Therefore a big factor is startup and shutdown speed. Containers are pretty bad there. Deno is better, and WASM is unbeatable, especially with things like Wizer[0]. [0]https://github.com/bytecodealliance/wizer https://github.com/bytecodealliance/wizer
- lucacasonato 5y ago
  Deno can in theory do the pre-initialization that wizer does for JS too. We have all of the infrastructure for it, we just have not gotten around to actually implementing it yet.
  - teleclimber 5y ago
    Issue 3335. I know. I'm watching it. :))
- electroly 5y ago
  Makes sense when talking about edge functions, but then OP started talking about Kubernetes. Our Kubernetes workloads don't resemble that at all; there's virtually none of that container startup/shutdown overhead to be concerned about. Most weeks, no containers are started or stopped at all.

olah_1 5y ago

I agree about WASM. I am sort of worried that Deno may be too late tbh. Why would I bother with an interpreted language at all when I can code in any language I want and run it anywhere with WASM?

deleted 5y ago
[deleted]
paulgb 5y ago
WASM still needs an interface layer to interact with the outside world (filesystem, etc.) My money is on WASI, but Deno becoming the interface layer has some advantages, mainly that most WASM-supporting languages already have tooling around JavaScript ffi.
teleclimber 5y ago
The "any language" advantage of WASM is theoretical. Each language is at a different level of support of WASM, libraries aren't all caught up and at the same point for all languages, etc... I love the promise of WASM, but every time I look at it I get lost in a sea of acronyms, and my optimistic ideas of using language X with library Y on runtime Z are dashed because there is some missing piece somewhere. If anything, the "any language" thing creates a giant matrix of potential pitfalls for the programmer. In comparison, the combination of JS/TS, the browser API and a solid std lib looks pretty good for some problems.
- irq-1 5y ago
  Agreed. There is also the lack of a GC in WASM and Denos' use of existing web standard APIs.
jrockway 5y ago
What is "any language" these days? I feel like WebAssembly's day will come when one of those is Javascript, and so far that hasn't happened. Go's support is pretty good (with tinygo offering a tiny runtime more suited to this application). Rust appears to support compiling directly to WebAssembly, and there are some smaller languages like AssemblyScript and Lua with support. I'm guessing plain C works fine. Then there are projects that compile the runtime for interpreted languages to WebAssembly, so you can theoretically run things like Python. Nobody is writing applications in C or AssemblyScript, so that leaves rust or go. If you're using one of those languages, though, you can just (cross-)compile a binary and copy it to a VM that is on some cloud provider's free tier, so this isn't really easing any deployment woes. It was already as easy with native code, so WebAssembly isn't adding much stuff here. (The isolation aspect was interesting in the days before Firecracker, but now every computer has hardware virtualization extensions and so you can safely run untrusted native code in a VM at native speeds.) Anyway, I always wanted WebAssembly for two things: 1) To compile my React apps to a single binary. 2) To use as a plugin system for third-party apps (so I don't have to recompile Nginx to have OpenTracing support, for example). The language support hasn't really enabled either, so I'm a little disappointed. (Disappointed isn't really fair. I've invested no effort in this, and I can't be disappointed that someone didn't make a really complicated thing for me for free. But you know what I mean.)

syrusakbary 5y ago

I fully agree with your take. I think JS-directed computation is very good towards short-term adoption (since running JS on the Edge is probably the most popular use case), but eventually the needs to run other programming languages at the Edge will likely eclipse the JS use case. At Wasmer [1] we have been working actively towards this future. Lately more companies have been also doing awesome work on these fronts: Lunatic, Suborbital, Cosmonic (WasmCloud) and Fermyon (Spin). However, each of us with a different take/vision on how to approach the future of Computation at the Edge. I'm very excited about to see what each approach will bring into the table. [1] https://wasmer.io/ https://wasmer.io/

dmitriid 5y ago

> mainly as a weapon against rising cloud deployment costs. Cloud Functions is literally code you're running in the cloud. And the moment you approach their limit(ation)s, you will see the same "rising cloud deployment costs" > Running a WASM engine on the cloud means ... a fraction of the overhead of a container or nodejs environment You do realise that there are other languages than javascript in nodejs? That there other environments than cloud functions? And that you can skip that overhead entirely by running with a different language in a different environment? Or even run Rust in AWS Lambda if you so wish? > so there’s no lock-in with the language that the Serverless provider mandates. And at the same time you're advertising for a runtime lock in. This doesn't compute. > Web pages that are as ancient as the early 90s are perfectly rendered even today... Basically, it means a WASM binary is future proof by default. It's not future proof. Web Pages from the 90s are not actually rendered perfectly today because browsers didn't agree on a standard rendering until late 2000s, and many web pages from the 90s and 2000s were targeting a specific browser's feature set and rendering quirks. Web Pages from the 90s are rendered good enough (and they had few things to render to begin with). As web's standards approach runaway asymptotical complexity, their "future-proofness" is also also questionable. Chrome broke audio [1], browsers are planning to remove alert/confirm/prompt [2], some specs are deprecated after barely seeing the light of day [3], some specs are just shitty and require backtracking or multiple additional specs on top to fix the most glaring holes, etc. > I've published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique "Let's replace somewhat unlimited code with severely limited, resource constrained code running in a slow VM in a shared instance" is not a good take. [1] https://www.usgamer.net/articles/google-chromes-latest-update-broke-a-bunch-of-browser-games https://www.usgamer.net/articles/google-chromes-latest-updat... [2] https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d [3] https://chromestatus.com/feature/4642138092470272 https://chromestatus.com/feature/4642138092470272 and https://www.w3.org/TR/html-imports/ https://www.w3.org/TR/html-imports/

atoav 5y ago
I sought to unserstand "serverless" but every deployment diagram I have ever seen show things that look an aweful lot like they run on... servers? Maybe I don't get the idea (and honestly I was too lazy to put in the legwork), but when I hear something like "serverless" I imagine some p2p javascript federated decentralized beast where the shared state is stored through magic and tricks with the users clients and there is literally no server anywhere to be found. Instead it seems like a buzzword (?) for a weirdly niche way of running things that someone with a 4 Euro/Month nginx instance that hosts 10 websites will probably never understand. Maybe I also don't need to understand because I know how to leverage static content, caching, fast Rust reverse proxy services and client side javascript to develope fast web stuff that gets the job done).

me_me_mu_mu 5y ago

Really, really dumb question. I've seen a lot of node/python/etc serverless offerings. Is there something where you just provide a binary and its executed each time? For example, I write a simple single responsibility piece of code in Go `add_to_cart.go` and build it, deploy it, and somehow map it to some network request. dot slash pass args, and return the result? No need to have containers or runtime?

kasey_junk 5y ago
AWS lambda’s work that way.
pid-1 5y ago
That's how every FaaS (Function as a Service) offering works. A caveat is that most non trivial applications need something more than running a function. You might need secrets management, ephemeral and non ephemeral storage, relational databases, non relational databases, dependency management, AAA capabilities, observability, queues/async, caching, custom domains... That's where said offerings differ. EDIT: actually most FaaS offerings take code as input, not binaries. I'm not sure if that was the relevant part of your question. If it was, then yeah I don't know of such service.
brundolf 5y ago
It's possible you'd run into environment issues. JS or Python code (or a container) doesn't have to care as much what OS or architecture it's run on. A raw binary could pierce that abstraction and make the service more complicated to offer.
qbasic_forever 5y ago
Find a cheap apache web host that allows cgi-bin.
nl 5y ago
You can do that on Lambda: https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.html https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.... AWS still needs the container/runtime to stop your code getting access to other things on the same physical computer.

api 5y ago

> I'm really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs. How would that work? Don't these tend to facilitate cloud lock-in or at least be cloud-only in the sense that they make it hard to operate your own metal infrastructure?

deleted 5y ago
[deleted]
kvz 5y ago
There is KNative for that. But really folks are using serverless to _not_ have to operate their own iron and save themselves an ops team.
- api 5y ago
  Sure. Just saying those savings only work if the cloud vendors are in fact charging reasonable rates on serverless compute, storage, and bandwidth. In my experience cloud vendors love to tow that line but if you do the math the savings over DIY are sometimes questionable. It depends on your work load.

adam_arthur 5y ago

Also a common spec for serverless is badly needed. Serverless code should be portable between different cloud providers, otherwise there's vendor lock in and much greater opportunity to price gouge. Anybody know if a common API for serverless components is being worked on?

gardnr 5y ago
There's the serverless framework which is easy to use and there is terraform which is more powerful. Relevant: https://xkcd.com/927/ https://xkcd.com/927/
- huijzer 5y ago
  It doesn’t avoid vendor lock-in. Instead of a cloud provider, it is now Terraform.
phphphphp 5y ago
Check out knative, it’s used for Google Cloud Run: https://knative.dev/docs/ https://knative.dev/docs/
- algorithmmonkey 5y ago
  What is the common spec for Knative? It seems like one runs an app as normal in a container and then the special scaling sauce is handled by Knative. When I think of a portable spec for serverless, I think of something more like a Trait of an Interface that needs to be implemented, less a app hosting model. If you think about it like that, then Web Assembly component model [1] would be a great fit for defining an interface that could be implemented in a variety of languages. [1]: https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md https://github.com/WebAssembly/component-model/blob/main/des...
  - adam_arthur 5y ago
    Yes, exactly. Of course experimentation and competition is good to settle on a solid set of building blocks, but in the long run serverless code should absolutely be portable between vendors. There's a strong incentive for vendors to not allow this as it reduces their pricing power... But think we will see it eventually one way or another.

melony 5y ago

The problem is database. Distributed serverless-first SQL like spanner, Cockroach, PlanetScale are very very expensive.

_ben_ 5y ago
We're building PolyScale[1] to address this problem. PolyScale is a serverless edge cache for databases so you can easily distribute your reads. We are opening up early access to our connection pooling features in the next couple of weeks which allows FaaS platforms like Netlify, Cloudflare etc to create large numbers of ephemeral connections, without impacting your origin database, as well as reducing connection latency significantly. [1] https://www.polyscale.ai/ https://www.polyscale.ai/
- tauwauwau 5y ago
  I was looking at the polyscale docs and found following PolyScale evaluates each SQL query in real-time and when it detects a DML query i.e. a SQL INSERT, UPDATE or DELETE, it extracts the associated tables for the query. Then, all data for the table(s) in question are purged from the cache, for every region globally. at https://docs.polyscale.ai/how-does-it-work/#smart-invalidation https://docs.polyscale.ai/how-does-it-work/#smart-invalidati... Isn't clearing cache for entire tables for a all DMLs which may be changing one record too intensive and how does this affect performance of cache when there are multiple DML queries being run every minute? Also can you please give the docs link to connection pooling feature
  - _ben_ 5y ago
    That’s right. Currently the auto invalidation is somewhat of a blunt instrument in that it will blow away all cache data related to the table(s) as default. That approach favors consistency over performance, but is also a natural fit to some query traffic patterns. You can also switch it off if you so desire. The next iteration that is imminent for release can be much more surgical, invalidating based on more of the query details. Connection pooling docs are coming soon as part of the feature early access launch. Feel free to drop me an email and I can let you know when its released. Im ben at our domain.

tedk-42 5y ago

Hmmm I had a look into WASM runtimes and the idea seems interesting to deploy something on a server as a lightweight execution environment (I think of Firecracker from AWS for VMs). To be honest on the server side of things containers are so nice because 99% of the time they include all your dependencies you need to run the app.

danamit 5y ago

in what world is serverless cheaper?

kvz 5y ago
The one where you only need a few invocations and with serverless: aren’t paying for an idling VM all of the other time. Arguably you may save yourself an ops team too.

youngtaff 5y ago

Fastly use WASM for their Edge Compute offering

yencabulator 5y ago

You can write Cloudflare Workers in WASM today. As far as I can tell from the outside, that's still "WASM-called-by-Javascript", and many of their JS optimizations don't work the same way. E.g. if a Worker calls JS `fetch` and returns that `Response`, they recognize that and remove the JS from the data path; same is not true for WASM at this time.

kentonv 5y ago
I think that optimization should still work when using Wasm, unless the Wasm code does something silly like manually pump the stream (read from one, write to the other), but I think you'd have to go out of your way to do that, and anyway the same is true of pure-JavaScript code.
- yencabulator 5y ago
  Ooh, that is great news. I've been itching to write a "proxy thing" in Rust instead of JS.