4 ms·

I think you're the one mistaken, here. The interface for cgi-bin was that you created a process per web request. The interface for Serverless is that you create

I think you're the one mistaken, here. The interface for cgi-bin was that you created a process per web request. The interface for Serverless is that you create a process per web request. The tooling is a lot better for Serverless, but I'd hesitate to call it 20 years better - I'd hesitate to call it 10 years better.

viraptor 7y ago
> The interface for Serverless is that you create a process per web request. That is not how it works in the most popular solutions. Both aws lambda and Google cloud functions will keep the server instance running after your first request and only dispatch function calls - you can cache data between requests in globals. That's also why the first cold request is so much slower (it actually loads the code for the first time). Most serverless function environments are much closer to managed fastcgi, than old cgi-bin approach. This is mentioned right in the service docs: https://cloud.google.com/functions/docs/concepts/exec#function_scope_versus_global_scope https://cloud.google.com/functions/docs/concepts/exec#functi... Also, thanks for proving my point - some people don't understand it's a meme, not real equivalence.
- exabrial 7y ago
  so it's not serverless then...
  - keanebean86 7y ago
    "Someone else handles the server instances and hardware while you just write the functions" doesn't have the same ring to it.
- spc476 7y ago
  Oh, so it's FastCGI then.
  - viraptor 7y ago
    Managed FastCGI with guaranteed execution environment, integrated deployment process, aggressive autoscaling and billed for usage rather than provisioned resources.
    - kbenson 7y ago
      So, FastCGI with good process accounting and limits. I get it, it's nice, but I agree with others it's mostly a nice extension and better api for CGIs. Oh, with better marketing of course.
    - majewsky 7y ago
      Soooooo... Heroku? :)
      - viraptor 7y ago
        No, you tell heroku how many dynos you're going to pay for, and you pay whether you fully utilised them or not. With lambda you don't declare that up front and get billed only for what was served.

viraptor 7y ago

> The interface for Serverless is that you create a process per web request. That is not how it works in the most popular solutions. Both aws lambda and Google cloud functions will keep the server instance running after your first request and only dispatch function calls - you can cache data between requests in globals. That's also why the first cold request is so much slower (it actually loads the code for the first time). Most serverless function environments are much closer to managed fastcgi, than old cgi-bin approach. This is mentioned right in the service docs: https://cloud.google.com/functions/docs/concepts/exec#function_scope_versus_global_scope https://cloud.google.com/functions/docs/concepts/exec#functi... Also, thanks for proving my point - some people don't understand it's a meme, not real equivalence.

exabrial 7y ago
so it's not serverless then...
- keanebean86 7y ago
  "Someone else handles the server instances and hardware while you just write the functions" doesn't have the same ring to it.
spc476 7y ago
Oh, so it's FastCGI then.
- viraptor 7y ago
  Managed FastCGI with guaranteed execution environment, integrated deployment process, aggressive autoscaling and billed for usage rather than provisioned resources.
  - kbenson 7y ago
    So, FastCGI with good process accounting and limits. I get it, it's nice, but I agree with others it's mostly a nice extension and better api for CGIs. Oh, with better marketing of course.
  - majewsky 7y ago
    Soooooo... Heroku? :)
    - viraptor 7y ago
      No, you tell heroku how many dynos you're going to pay for, and you pay whether you fully utilised them or not. With lambda you don't declare that up front and get billed only for what was served.