10 ms·

For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement

For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement for cost savings.

jeffbee 6y ago
Just out of curiosity, what are you getting out of your 160 million CPU cycles? Are you mostly on the CPU, or mostly waiting for something (database call or whatever)?
- londons_explore 6y ago
  I want to do something that a low level hacker could do in 100 clock cycles with hardcoded bit twiddling and some avx-512, but I want to use nodejs, so I'm gonna need at least 100 million clock cycles to parse all the npm modules...
  - fwip 6y ago
    Not sure why you need a whole bunch of npm modules to do bit twiddling in a performance-sensitive lambda function. Sounds like you just don't like Javascript. Edit: You're spending like 80ms on cold-start of your lambda function, plus network overhead. If you can spare that, you can likely spare the half a millisecond for the 999,900 cycles you're complaining about.
Supermancho 6y ago
> So this is a pretty good advancement for cost savings. For some people. Those cost savings are made up somewhere else. Ultimately, Amazon is not a loss leader.
- camhart 6y ago
  Why only for some people? It always rounded up to 100ms. If your function took 101ms, it was billed as 200ms.
  - jlouis 6y ago
    If it takes 60 seconds, that's 600 steps. 601 steps isn't that much of a saving. It matters close to 0.
    - NeutronStar 6y ago
      If your lambda function took 60s you have other issues.
    - alpha_squared 6y ago
      If a process takes that long, lambda would be a poor architectural choice.
      - Pfhreak 6y ago
        Not necessarily. For low frequency workloads with reasonably long step times, Lambda can still make sense. (E.g. When videos appear in this S3 bucket, process them.) You might only drop videos in once a week, but when you do you want to run some code against them. There are plenty of distributed workflow reasons to run long running Lambdas infrequently rather than spinning up and down an EC2 instance.
        lstamour 6y ago
        Right but the first thought I had was, couldn’t you fan out and run a lambda for each frame or a group of related frames? (E.g. Batch HLS processing would be really easy!) If so, you’re back to short lambdas again. It’s really the sweet spot for using Lambda after all: lots of big jobs can be broken down into lots of little jobs, etc.
        Pfhreak 6y ago
        Plausibly. But that might be more effort than just writing the code to ingest a video file (or some other big data blob) in the simplest, most straightforward way possible.
        6y ago
- Smaug123 6y ago
  … yes? I don't use AWS Lambda at all, so I don't see any cost savings. It's implicit that not everyone will see the savings.
- bpodgursky 6y ago
  If Amazon reduces costs behind the scenes, they can maintain the same revenue while lowering prices for everyone, by helping people deploy previously cost-prohibitive infrastructure. (ie, if people now use 1.5x as many Lambdas, they can lower costs by 1/3, and everyone wins).
  - pdelgallego 6y ago
    The Jevons paradox applies to compute. In economics, the Jevons paradox occurs when technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises due to increasing demand. The more efficient (or cheaper) compute gets the more uses we find for it, rising the consumption of it. People think about pricing as a zero sum game. In reality, there are very few things in the world that are zero sum games.
- vikramkr 6y ago
  This is also a competitive market. Aws has to fight against gcp and azure for new customers, and in a competitive market, you don't get a guarantee to make up the money you lose somewhere else.
tgv 6y ago
Warm or cold?
munns 6y ago
Awesome! That was the idea here. Lots of sub 100ms workloads and we really want you to be able to pay for what you use. - Chris, Serverless@AWS
- ignoramous 6y ago
  > ...we really want you to be able to pay for what you use. Cloudflare Workers has the right pricing model. They only charge for CPU time and not wall time. They also do not charge for bandwidth. > Lots of sub 100ms workloads... AWS Lambda (or Lambda at Edge), as it stands, is 10x more expensive for sub 50ms workloads (Workers does allow upto 100ms for the 99.9th percentile) that can fit 128MB RAM. https://medium.com/@zackbloom/serverless-pricing-and-costs-aws-lambda-and-lambda-edge-169bfb58db75 https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
  - munns 6y ago
    Except that none of the rest of your infrastructure is there, and that APIs represent just a non-majority part of Lambda workloads.
    - mrits 6y ago
      To be clear, you're acknowledging Cloudflare has a much better pricing model but just not as many other services yet?
      - munns 6y ago
        No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think. They aren't brought up in any of the convos I have with customers.
        ignoramous 6y ago
        But you're telling us that Lambda's prices are justifiably higher because of the strong vendor lock-in? AWS is starting to sound more like Oracle. Ironic. :) Besides the fact that Cloudflare's part of the Bandwidth Alliance with GCP and other infrastructure providers from which AWS is conspicuously absent, Cloudflare's also slowly but surely building a portfolio of cloud services.
eb0la 6y ago
So this confirms there is a lot of competition in the serverless space: aws lambda, Azure cloud functions, Google cloud functions, serverless containers. Like knative, Google cloud run...
jimmaswell 6y ago
How many people actually use lambda? Always came off as a gimmick to me.
- munns 6y ago
  Enough that in 2019 it was the most popular topic at re:Invent (our big user conference) and that today per our re:Invent announcement almost half of all new compute workloads in Amazon are based on it. Pretty heavily used across different industries and verticals.
- diegocg 6y ago
  They can seem not that useful by themselves. Their power comes from the integration with the rest of AWS services.
- tealpod 6y ago
  I rarely use lambda but I use alot of Google firebase-functions for majority of my server code. From my experience lambda/firebase-functions/Azure-functions are very popular.One simple usecase I can tell is payment-successful return-hook from payment servers like Stripe.Its a tiny task which just logs payment-success info and triggers a email..etc.
franga2000 6y ago
Just out of curiosity, could you share what kind of things you use it for? I've never used Lambda, but any time I have a function that I need to run in response to some event or perodically (that's what Lambda is, right?), it's set up in a background worker specifically because it's long and slow, as anything fast can be done synchronously without the overhead.
- Cthulhu_ 6y ago
  Lambda is not specifically made for long and slow tasks; AWS Lambda specifically has a maximum execution time of 15 minutes (and you have to explicitly configure it to do so, see https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambda-supports-functions-that-can-run-up-to-15-minutes/#:~:text=You%20can%20now%20configure%20your,Lambda%20function%20was%205%20minutes https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambd....). For longer tasks, spinning up an EC2 or Beanstalk instance is probably the way to go. As for what to use it for, we used it in our application (deployed to Netlify which uses Lambda under the hood) where lambdas operated like a 'proxy' to various 3rd party API suppliers (Commercetools, Adyen, some age verification service), and those too would use a lambda function to ping back at us (e.g. when payment was confirmed). Worked pretty well, although in retrospect I would've preferred a 'normal', monolithic server to do the same thing.

For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement for cost savings.

jeffbee 6y ago

Just out of curiosity, what are you getting out of your 160 million CPU cycles? Are you mostly on the CPU, or mostly waiting for something (database call or whatever)?

londons_explore 6y ago
I want to do something that a low level hacker could do in 100 clock cycles with hardcoded bit twiddling and some avx-512, but I want to use nodejs, so I'm gonna need at least 100 million clock cycles to parse all the npm modules...
- fwip 6y ago
  Not sure why you need a whole bunch of npm modules to do bit twiddling in a performance-sensitive lambda function. Sounds like you just don't like Javascript. Edit: You're spending like 80ms on cold-start of your lambda function, plus network overhead. If you can spare that, you can likely spare the half a millisecond for the 999,900 cycles you're complaining about.

Supermancho 6y ago

> So this is a pretty good advancement for cost savings. For some people. Those cost savings are made up somewhere else. Ultimately, Amazon is not a loss leader.

camhart 6y ago
Why only for some people? It always rounded up to 100ms. If your function took 101ms, it was billed as 200ms.
- jlouis 6y ago
  If it takes 60 seconds, that's 600 steps. 601 steps isn't that much of a saving. It matters close to 0.
  - NeutronStar 6y ago
    If your lambda function took 60s you have other issues.
  - alpha_squared 6y ago
    If a process takes that long, lambda would be a poor architectural choice.
    - Pfhreak 6y ago
      Not necessarily. For low frequency workloads with reasonably long step times, Lambda can still make sense. (E.g. When videos appear in this S3 bucket, process them.) You might only drop videos in once a week, but when you do you want to run some code against them. There are plenty of distributed workflow reasons to run long running Lambdas infrequently rather than spinning up and down an EC2 instance.
      - lstamour 6y ago
        Right but the first thought I had was, couldn’t you fan out and run a lambda for each frame or a group of related frames? (E.g. Batch HLS processing would be really easy!) If so, you’re back to short lambdas again. It’s really the sweet spot for using Lambda after all: lots of big jobs can be broken down into lots of little jobs, etc.
        Pfhreak 6y ago
        Plausibly. But that might be more effort than just writing the code to ingest a video file (or some other big data blob) in the simplest, most straightforward way possible.
      - 6y ago
Smaug123 6y ago
… yes? I don't use AWS Lambda at all, so I don't see any cost savings. It's implicit that not everyone will see the savings.
bpodgursky 6y ago
If Amazon reduces costs behind the scenes, they can maintain the same revenue while lowering prices for everyone, by helping people deploy previously cost-prohibitive infrastructure. (ie, if people now use 1.5x as many Lambdas, they can lower costs by 1/3, and everyone wins).
- pdelgallego 6y ago
  The Jevons paradox applies to compute. In economics, the Jevons paradox occurs when technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises due to increasing demand. The more efficient (or cheaper) compute gets the more uses we find for it, rising the consumption of it. People think about pricing as a zero sum game. In reality, there are very few things in the world that are zero sum games.
vikramkr 6y ago
This is also a competitive market. Aws has to fight against gcp and azure for new customers, and in a competitive market, you don't get a guarantee to make up the money you lose somewhere else.

tgv 6y ago

Warm or cold?

munns 6y ago

Awesome! That was the idea here. Lots of sub 100ms workloads and we really want you to be able to pay for what you use. - Chris, Serverless@AWS

ignoramous 6y ago
> ...we really want you to be able to pay for what you use. Cloudflare Workers has the right pricing model. They only charge for CPU time and not wall time. They also do not charge for bandwidth. > Lots of sub 100ms workloads... AWS Lambda (or Lambda at Edge), as it stands, is 10x more expensive for sub 50ms workloads (Workers does allow upto 100ms for the 99.9th percentile) that can fit 128MB RAM. https://medium.com/@zackbloom/serverless-pricing-and-costs-aws-lambda-and-lambda-edge-169bfb58db75 https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
- munns 6y ago
  Except that none of the rest of your infrastructure is there, and that APIs represent just a non-majority part of Lambda workloads.
  - mrits 6y ago
    To be clear, you're acknowledging Cloudflare has a much better pricing model but just not as many other services yet?
    - munns 6y ago
      No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think. They aren't brought up in any of the convos I have with customers.
      - ignoramous 6y ago
        But you're telling us that Lambda's prices are justifiably higher because of the strong vendor lock-in? AWS is starting to sound more like Oracle. Ironic. :) Besides the fact that Cloudflare's part of the Bandwidth Alliance with GCP and other infrastructure providers from which AWS is conspicuously absent, Cloudflare's also slowly but surely building a portfolio of cloud services.

eb0la 6y ago

So this confirms there is a lot of competition in the serverless space: aws lambda, Azure cloud functions, Google cloud functions, serverless containers. Like knative, Google cloud run...

jimmaswell 6y ago

How many people actually use lambda? Always came off as a gimmick to me.

munns 6y ago
Enough that in 2019 it was the most popular topic at re:Invent (our big user conference) and that today per our re:Invent announcement almost half of all new compute workloads in Amazon are based on it. Pretty heavily used across different industries and verticals.
diegocg 6y ago
They can seem not that useful by themselves. Their power comes from the integration with the rest of AWS services.
tealpod 6y ago
I rarely use lambda but I use alot of Google firebase-functions for majority of my server code. From my experience lambda/firebase-functions/Azure-functions are very popular.One simple usecase I can tell is payment-successful return-hook from payment servers like Stripe.Its a tiny task which just logs payment-success info and triggers a email..etc.

franga2000 6y ago

Just out of curiosity, could you share what kind of things you use it for? I've never used Lambda, but any time I have a function that I need to run in response to some event or perodically (that's what Lambda is, right?), it's set up in a background worker specifically because it's long and slow, as anything fast can be done synchronously without the overhead.

Cthulhu_ 6y ago
Lambda is not specifically made for long and slow tasks; AWS Lambda specifically has a maximum execution time of 15 minutes (and you have to explicitly configure it to do so, see https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambda-supports-functions-that-can-run-up-to-15-minutes/#:~:text=You%20can%20now%20configure%20your,Lambda%20function%20was%205%20minutes https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambd....). For longer tasks, spinning up an EC2 or Beanstalk instance is probably the way to go. As for what to use it for, we used it in our application (deployed to Netlify which uses Lambda under the hood) where lambdas operated like a 'proxy' to various 3rd party API suppliers (Commercetools, Adyen, some age verification service), and those too would use a lambda function to ping back at us (e.g. when payment was confirmed). Worked pretty well, although in retrospect I would've preferred a 'normal', monolithic server to do the same thing.