6 ms·

One thing that strikes me as having really promising possibilities for doing something Lambda-esque is systemd socket activation [1]. You can essentially have n

One thing that strikes me as having really promising possibilities for doing something Lambda-esque is systemd socket activation [1]. You can essentially have no running services, and systemd will hold open a socket (port/unix/etc) and then it will spin up a given service if a request is made on that socket. As long as you build your "service" to handle a single request and shut down (maybe have an external db-access service to avoid add'l connection overhead), I'd imagine you get something very similar to what Lambda offers - high density, on-demand computing. [1] http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... and http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html

digitalsanctum 11y ago
Along these lines I started a pet project [1] to enable reusing artifacts (Java) uploaded to AWS Lambda to also be self-hosted. One of the last tasks I have left is to dynamically run a container based on the incoming request similarly outlined here [2]. [1] https://github.com/digitalsanctum/lambda https://github.com/digitalsanctum/lambda [2] https://developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/ https://developer.atlassian.com/blog/2015/03/docker-systemd-...
- nabaraz 11y ago
  Your github link is 404
  - digitalsanctum 11y ago
    I realized I hadn't yet made the repo public. It is now :)
    - samstave 11y ago
      Check for keys!!! :-)
digikata 11y ago
https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd ?
- andrewstuart2 11y ago
  If you go to the second link I provided, Poettering explicitly mentions inetd. He also elaborates on what makes socket activation different.
Twirrim 11y ago
Welcome to inetd/xinetd. They've been around for a long time :)
rakoo 11y ago
As others have said, this is basically what inetd and the likes have been doing for a long time. The reason why it isn't used for heavy services anymore is that every request will spawn a new process, and that's extremely expensive. That's like CGI at the socket level. The natural "solution" you have is to let your process run, and every time a new request comes from the network, it is merely redirected to your process, possibly under another format; that's FastCGI for you. But then you lose the simplicity of programming your process as if it were called for every request. The real innovation that Lambda brings on the table is container reuse [1]. Basically your process is started in a container the very first time a request hits Lambda, and the initialization step happens; when it's done the container is "snapshotted" and runs the request. If the request has been completely processed, the process should normally close, but instead the container is kept hot for the next requests. If they come not too far away, the container will be reused, right after the snapshot, as if it was run for the first time. Because of this trickery having many requests is not so expensive anymore, there can be very little latency. Bring that to everyone and inetd/xinetd/systemd's socket activation can be seriously considered as a viable solution. [1] https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/ https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...
- andrewstuart2 11y ago
  Seems like you could essentially implement an LRU container/process/etc. keepalive on top of <insert socket activation tech> and have your machines essentially fully-utilized with minimal latency for services being accessed recently.
  - rakoo 11y ago
    No, what Lambda does is take your equivalent of CGI script, init it once and reuse the snapshot afterwards. It is completely oblivious to the process. As far as it is concerned, your script is just "take this from STDIN, do the magic, write on STDOUT and exit". There is no notion of keepalive because the script itself isn't supposed to stay alive. All the magic happens in the execution of the script.

digitalsanctum 11y ago

Along these lines I started a pet project [1] to enable reusing artifacts (Java) uploaded to AWS Lambda to also be self-hosted. One of the last tasks I have left is to dynamically run a container based on the incoming request similarly outlined here [2]. [1] https://github.com/digitalsanctum/lambda https://github.com/digitalsanctum/lambda [2] https://developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/ https://developer.atlassian.com/blog/2015/03/docker-systemd-...

nabaraz 11y ago
Your github link is 404
- digitalsanctum 11y ago
  I realized I hadn't yet made the repo public. It is now :)
  - samstave 11y ago
    Check for keys!!! :-)

digikata 11y ago

https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd ?

andrewstuart2 11y ago
If you go to the second link I provided, Poettering explicitly mentions inetd. He also elaborates on what makes socket activation different.

Twirrim 11y ago

Welcome to inetd/xinetd. They've been around for a long time :)

rakoo 11y ago

As others have said, this is basically what inetd and the likes have been doing for a long time. The reason why it isn't used for heavy services anymore is that every request will spawn a new process, and that's extremely expensive. That's like CGI at the socket level. The natural "solution" you have is to let your process run, and every time a new request comes from the network, it is merely redirected to your process, possibly under another format; that's FastCGI for you. But then you lose the simplicity of programming your process as if it were called for every request. The real innovation that Lambda brings on the table is container reuse [1]. Basically your process is started in a container the very first time a request hits Lambda, and the initialization step happens; when it's done the container is "snapshotted" and runs the request. If the request has been completely processed, the process should normally close, but instead the container is kept hot for the next requests. If they come not too far away, the container will be reused, right after the snapshot, as if it was run for the first time. Because of this trickery having many requests is not so expensive anymore, there can be very little latency. Bring that to everyone and inetd/xinetd/systemd's socket activation can be seriously considered as a viable solution. [1] https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/ https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

andrewstuart2 11y ago
Seems like you could essentially implement an LRU container/process/etc. keepalive on top of <insert socket activation tech> and have your machines essentially fully-utilized with minimal latency for services being accessed recently.
- rakoo 11y ago
  No, what Lambda does is take your equivalent of CGI script, init it once and reuse the snapshot afterwards. It is completely oblivious to the process. As far as it is concerned, your script is just "take this from STDIN, do the magic, write on STDOUT and exit". There is no notion of keepalive because the script itself isn't supposed to stay alive. All the magic happens in the execution of the script.