3 ms·
Ok I’ll bite. The argument here is that serverless is similar to cgi (common gateway interface, the original way a web server handed requests to an executable)
by carlsborg 7y ago
Ok I’ll bite. The argument here is that serverless is similar to cgi (common gateway interface, the original way a web server handed requests to an executable) in that they both spawn a process for each ‘dynamic’ backend request (static files are served from a cdn in serverless model).
This is of course a false and misleading analogy - the reason spawning a new process for each request is bad is that it doesn’t scale on a single server, but in the serverless model the infrastructure serving this is scaled up exactly so you don’t have to worry about this aspect.
Response times are measurably very good for go python and js, in our experience, and aws serverless will try to reuse you running process for subsequent requests (warm start).
And most importantly — there are no servers to manage.
- deaddodo 7y ago> Response times are measurably very good for go python and js, in our experience, and aws serverless will try to reuse you running process for subsequent requests (warm start). This is because most modern serverless implementations are closer to FastCGI (which had similar benefits over classic CGI). But the concepts are the same.