[motorest]

> I currently need a container if I need to handle literally anything besides HTTP

You don't. A container only handles concerns such as deployment and configuration. Containers don't speak HTTP either: they open ports and route traffic at a OSI layer lower than HTTP's.

[conradev]

Yes! All I was trying to say:

Containers can contain code which open arbitrary ports using the provided kernel interface whereas serverless workers cannot. Workers can only handle HTTP using the provided HTTP interface.

I don’t need a container, sure, I need a system with a network sockets API.

[mdaniel]

FWIW, Lambda takes the opposite of your assertion: there are function entrypoints and the HTTP or gRPC or Stdin is an implementation detail; one can see that in practice via the golang lambda "bootstrap" shim <https://pkg.go.dev/github.com/aws/aws-lambda-go@v1.49.0/lamb...> which is invoked by the Runtime Interface Emulator <https://github.com/aws/aws-lambda-runtime-interface-emulator...>

I don't have the links to Azure's or GCP's function emulation framework, but my recollection is that they behave similarly, for similar reasons

[conradev]

Oh yes! I was thinking about the V8 isolate flavor of stateless functions (Cloudflare, Fastly, etc). I had forgotten about the containerized Linux microVM stateless functions (Lambda, Cloud Run, etc). They have everything, and my favorite use is https://github.com/stanfordsnr/gg

Funnily, enough, the V8 isolates support stdio via WASM now

[motorest]

> Workers can only handle HTTP using the provided HTTP interface.

Not true. Cloudflare Workers support Cron triggers and RPC calls in the form of service bindings. Also, Cloudflare Queues support consumer workers.

Claiming "Workers can only handle HTTP" is also meaningless as HTTP is also used to handle events. For example, Cloudflare Queues supports consumers using HTTP short polling.

[conradev]

You forgot email, too!

But I still can't handle SSH or proxy WireGuard or anything like that (yet!)