3 ms·

Speed and parallelism are good features but the killer app of serverless is the cost savings. You only pay for the time your function is running. Traditional s

by efnx 6y ago

Speed and parallelism are good features but the killer app of serverless is the cost savings. You only pay for the time your function is running. Traditional server applications can be rewritten “serverless” so long as your pipeline is pretty functional, ie you’re not saving critical state in memory on the server process itself.

threeseed 6y ago
For some use cases the cost saving is a big deal e.g. resizing an incoming stream of images. But for the majority of apps it doesn't save that much. And it still pales in comparison to the cost of the engineers. Which often spend significantly more time to build, debug, test etc a serverless app than one they just throw on an EC2 server.
- efnx 6y ago
  “Apps” is a pretty vague description of an application, but if you’re writing a server it’s just as easy to “just throw” the app on lambda as it is on EC2. In general I ask myself if my new server can run on a lambda and if it can’t then I reach for something else. Most of the time it can.
tsimionescu 6y ago
> Traditional server applications can be rewritten “serverless” so long as your pipeline is pretty functional, ie you’re not saving critical state in memory on the server process itself. And if you're storing things in DB, how long does it take for your lambda to start up now? In a project I was on, it could easily take 3s for a new request to be served, because we had a lambda that was doing and auth check with the DB, and then a different lambda that was doing the actual application stuff with another DB. So not only would we incur the cold start cost twice, but, since our lambdas needed a nic inside a VPC to talk to the DB, the cold start cost was huge. And of course, you pay that cost for each additional concurrent connection, not just once. Of course, if we had stored everything in some other managed service, and maybe used some managed auth scheme, this would have not been a problem. AWS likes it when they get you hook, line and sinker.
- ElFitz 6y ago
  Was the first lambda waiting on the second's result before returning? If so, you really shouldn't rely on synchronously invoking à lambda from within another lambda. Also, things stored in the global scope (in Node.js functions) are kept between different invocations of a same container. If it can help...
  - tsimionescu 6y ago
    Not explicitly, this was orchestrated through the API Gateway authentication support. And yes, different invocations of the same container helped significantly (most importantly, the interface was already deployed in the private network), that is why I said that the problem was concurrent access. You could serve a pretty good number of users/second, but each user that happened to send a request while the already deployed containers were all busy would have to wait for up to 3s before we could give them any data from the backend. And of course, if two new users came in parallel, they would both have to wait, etc.
    - ElFitz 6y ago
      Ok, I see. And the VPC explains the high cold start. Only "solution" I see would be to "keep your functions warm" (there's a feature now for that), but it's more of an inconvenient useful anti- pattern to me. Quite annoying. Sorry I can't be of any more help :/
      - tsimionescu 6y ago
        I am still wondering if there is any way to get good lambda performance with a DB that is neither managed by AWS and not publically accessible.

by efnx 6y ago

threeseed 6y ago

For some use cases the cost saving is a big deal e.g. resizing an incoming stream of images. But for the majority of apps it doesn't save that much. And it still pales in comparison to the cost of the engineers. Which often spend significantly more time to build, debug, test etc a serverless app than one they just throw on an EC2 server.

efnx 6y ago
“Apps” is a pretty vague description of an application, but if you’re writing a server it’s just as easy to “just throw” the app on lambda as it is on EC2. In general I ask myself if my new server can run on a lambda and if it can’t then I reach for something else. Most of the time it can.

tsimionescu 6y ago

> Traditional server applications can be rewritten “serverless” so long as your pipeline is pretty functional, ie you’re not saving critical state in memory on the server process itself. And if you're storing things in DB, how long does it take for your lambda to start up now? In a project I was on, it could easily take 3s for a new request to be served, because we had a lambda that was doing and auth check with the DB, and then a different lambda that was doing the actual application stuff with another DB. So not only would we incur the cold start cost twice, but, since our lambdas needed a nic inside a VPC to talk to the DB, the cold start cost was huge. And of course, you pay that cost for each additional concurrent connection, not just once. Of course, if we had stored everything in some other managed service, and maybe used some managed auth scheme, this would have not been a problem. AWS likes it when they get you hook, line and sinker.

ElFitz 6y ago
Was the first lambda waiting on the second's result before returning? If so, you really shouldn't rely on synchronously invoking à lambda from within another lambda. Also, things stored in the global scope (in Node.js functions) are kept between different invocations of a same container. If it can help...
- tsimionescu 6y ago
  Not explicitly, this was orchestrated through the API Gateway authentication support. And yes, different invocations of the same container helped significantly (most importantly, the interface was already deployed in the private network), that is why I said that the problem was concurrent access. You could serve a pretty good number of users/second, but each user that happened to send a request while the already deployed containers were all busy would have to wait for up to 3s before we could give them any data from the backend. And of course, if two new users came in parallel, they would both have to wait, etc.
  - ElFitz 6y ago
    Ok, I see. And the VPC explains the high cold start. Only "solution" I see would be to "keep your functions warm" (there's a feature now for that), but it's more of an inconvenient useful anti- pattern to me. Quite annoying. Sorry I can't be of any more help :/
    - tsimionescu 6y ago
      I am still wondering if there is any way to get good lambda performance with a DB that is neither managed by AWS and not publically accessible.