AWS Lambda pricing now per ms • Hacker News Board

Re: AWS Lambda pricing now per ms

#31

Post by cle » Tue, Dec 01, 2020, 5:32 PM UTC

brunoluiz wrote: post #18

I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS

IME Lambda functions are mostly sitting around waiting on I/O, so I don't think it would make much of a difference for those workloads. The important technical factors for those workloads are startup time and I/O capabilities...JS is strong in both of those areas. For simple Lambda functions JS still seems like a great choice, along with Go. Rust would be overkill IMO unless you need to share a codebase or aren't I/O bound or have some other unique requirements.

Re: AWS Lambda pricing now per ms

#32

Post by trisiak » Tue, Dec 01, 2020, 5:36 PM UTC

irrational wrote: post #25

astuyvenberg wrote: post #14

Earlier quoted context omitted.

It's nice to see that AWS is using their economy of scale to reduce their own costs, and passing that on to the consumer.

I don't think they are doing it to be nice to consumers. I think they are doing it to cost less than competitors.

Isn't that the same in practice?

You get customers by being nice to them. Being nice to customers means competitive pricing, high quality support, good documentation, easy integration, etc. It's all driving towards the same goal.

Re: AWS Lambda pricing now per ms

#33

Post by Pfhreak » Tue, Dec 01, 2020, 5:37 PM UTC

alpha_squared wrote: post #27

jlouis wrote: post #17

Earlier quoted context omitted.

If it takes 60 seconds, that's 600 steps. 601 steps isn't that much of a saving. It matters close to 0.

If a process takes that long, lambda would be a poor architectural choice.

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.

Re: AWS Lambda pricing now per ms

#34

Post by philosopher1234 » Tue, Dec 01, 2020, 5:39 PM UTC

tgv wrote: post #26

brunoluiz wrote: post #18

I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS

I've got bad experiences with go startup (i.e., cold runs). They're much more expensive than I would have expected. If node can indeed run in 40ms (as https://news.ycombinator.com/item?id=25267211 says), then I'm surely going back to JS.

What is your experience? Go is an AOT compiled language so the only thing I could imagine you running into on startup is loading the binary into memory? Theres not a cold-start issue with Go, as its not an optimizing JIT.

Edit: Bizarre. Seems like Go on lambda does actually have slower cold start than JS or Python. I wonder if its just that the binary is likely larger than the equivalent JS source code? https://levelup.gitconnected.com/aws-lambda-cold-start-langu...

Re: AWS Lambda pricing now per ms

#35

Post by gabipurcaru » Tue, Dec 01, 2020, 5:40 PM UTC

tgv wrote: post #26

brunoluiz wrote: post #18

I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS

I've got bad experiences with go startup (i.e., cold runs). They're much more expensive than I would have expected. If node can indeed run in 40ms (as https://news.ycombinator.com/item?id=25267211 says), then I'm surely going back to JS.

same. I went through the trouble of implementing my function in Rust (Rocket), and it's actually quite slow because (a) startup is slow and (b) async/await is still pretty painful to use so I'm blocking on IO

Re: AWS Lambda pricing now per ms

#36

Post by k__ » Tue, Dec 01, 2020, 5:41 PM UTC

brunoluiz wrote: post #18

I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS

On the one hand I read that JS Lambdas were often already under 100ms (30-50ms)

On the other hand I heard legends about under 10ms Rust Lambdas.

Re: AWS Lambda pricing now per ms

#37

Post by jedberg » Tue, Dec 01, 2020, 5:41 PM UTC

AndersSandvik wrote: post #24

66$ for running a AWS Lambda with 128 for a year seems very expensive.

If you're running it continuously for a year, then you should probably be using a reserved instance and not lambda. Lambda is for short bursts, not 1 year of continuous use.

Re: AWS Lambda pricing now per ms

#38

Post by donor20 » Tue, Dec 01, 2020, 5:41 PM UTC

astuyvenberg wrote: post #15

4lejandrito wrote: post #10

I am impressed that computation is billed by the ms nowadays. I'm an ignorant in AWS Lambda but how do you know if their ms measurement is accurate? Is there any way to verify this?

It's still measured by wall clock time - not CPU time. I'd love to see them bill for actual CPU time.

They would be willing to do this probably if you let them evict your entire workload from memory during the period you were not paying for it, and then were able to charge you for CPU time and some additional charge to reload workload into memory from hibernation.

Most workloads ALSO hold memory (which is a key constraint) over the entire wall clock time, and the delays and impacts/costs of hibernating out the memory and then bringing it back so you can just be charged for CPU time may not make sense.

Re: AWS Lambda pricing now per ms

#39

Post by jedberg » Tue, Dec 01, 2020, 5:42 PM UTC

yeldarb wrote: post #3

Anyone know why there's a hard limit of 15 minutes for Lambda (and 9 minutes for Google Cloud Functions)? Still seems really weird to me.

Bin packing. It's a lot easier to distribute workloads around a cluster of compute if you can guarantee the maximum runtime.

Re: AWS Lambda pricing now per ms

#40

Post by donor20 » Tue, Dec 01, 2020, 5:42 PM UTC

yowlingcat wrote: post #16

yeldarb wrote: post #3

Anyone know why there's a hard limit of 15 minutes for Lambda (and 9 minutes for Google Cloud Functions)? Still seems really weird to me.

Lambda isn't designed for long running processes. Keeping the runtime limit lower makes it a lot easier to operate the underlying metal because you can move thing around every N minutes where N is the runtime limit. For long-running processes, something like Fargate might be a better fit in the AWS side of things.

Fargate works well especially after they fixed some of the pricing issues there. Then next step you can spin up a fleet of EC2 or EKS or something