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

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...