3 ms·

> there is no network addressability of serverless functions Didn't inetd (4.3BSD, June 1986) solve the problem?

• rhizome 8y ago
  You're not wrong.
• marcosdumay 8y ago
  There is nothing stopping inetd services from sharing disk data or communicating with other local services.
  • snaky 8y ago
    The particular inetd was just an example, but even for use with exact inetd from 1986, there are many solutions in modern operating systems to restrict any process, like SELinux, AppArmor, Seccomp and capabilities, LXC unprivileged containers and whatnot.
• comex 8y ago
  No. It solved a problem that was vaguely analogous if you consider a binary sitting on some Unix server the equivalent of a “serverless function”. They are somewhat similar, in that both are relatively self-contained and stateless compared to the alternative, not requiring anything to be explicitly spun up or down (a daemon or a VM/container respectively). But an inetd binary runs on an existing server, and the client is expected to know the address of the server. A “serverless function” can be spun up on the fly on any number of provider-owned servers which nobody has seen before, so there needs to be a separate mechanism to (1) request a server to spin up if necessary and (2) locate that server. Right now, Amazon Lambda only provides this through high-level abstractions such as Amazon API Gateway; you can’t even listen on a port from a Lambda container, so you’re limited by the speed of those gateways.
  • regularfry 8y ago
    "Locate that server" is DNS. Or possibly reverse proxying, if DNS is hard and Apache is easy. Transparent elasticity is the fundamental advance here, and it seems to come with a surprising number of tradeoffs.