Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Behind the scenes, AWS Lambda

bschaatsbergen.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Behind the scenes, AWS Lambda

#81

Post by carlosf »

otterley wrote: post #78
simonw wrote: post #71

Earlier quoted context omitted.

"Easily pause and resume your App Runner applications using the console, CLI, or API. You’re only billed when the service is running." That doesn't sound like the automated scale-to-zero I get from Cloud Run.

It does scale to zero CPU when your application isn’t serving requests. See the pricing model at https://aws.amazon.com/apprunner/pricing/ for more details. It does not scale to zero memory, however, because customers have told us that cold-start latency has been their biggest pain point with Lambda functions. App Runner containers can respond to requests in milliseconds as a result.

I have the opposite use case.

Most of the stuff my company is running is made up of data pipelines and machine learning pipelines. So we have a lot of infrequent jobs that don't really care about latency.

Re: Behind the scenes, AWS Lambda

#82

Post by simonw »

ignoramous wrote: post #75
simonw wrote: post #39

Earlier quoted context omitted.

When I say "scale to zero" I mean like Cloud Run or AWS Lambda: I define it as the service automatically scaling to zero (and hence costing nothing to run) in between requests, but automatically starting up again when a new request comes in - so the request still gets served, it just suffers from a few seconds of cold-start time. I'm pretty sure Fargate doesn't offer this. It sounds like you're talking about the abil…

Curious, have you used Cloudflare Workers Unbound to see how it compares with Cloud Run in terms of pricing and cold starts?

I haven't yet - my projects (all based around https://datasette.io/) need full Python support, and it looks like Cloudflare Workers still only with with JavaScript or stuff-that-compiles-to-JavaScript. I don't think I can get Datasette working via the Python-to-JavaScript route, it has too many C dependencies (like SQLite).

Re: Behind the scenes, AWS Lambda

#83

Post by valenterry »

rejectedandsad wrote: post #80
valenterry wrote: post #63

Earlier quoted context omitted.

Yeah, except for the lambda time limit...

Given most things are frontended by API Gateway anyway this isn’t too big of a concern since there’s already an effective 30 second timeout there. For ETL like stuff you can use Stepfunctions too.

It's still sad, because then you need a lambda for just these one or two things that might run long (or maybe even forever) and now you have to mix lambda and e.g. ECS.

Re: Behind the scenes, AWS Lambda

#84

Post by otterley »

carlosf wrote: post #81
otterley wrote: post #78

Earlier quoted context omitted.

It does scale to zero CPU when your application isn’t serving requests. See the pricing model at https://aws.amazon.com/apprunner/pricing/ for more details. It does not scale to zero memory, however, because customers have told us that cold-start latency has been their biggest pain point with Lambda functions. App Runner containers can respond to requests in milliseconds as a result.

I have the opposite use case. Most of the stuff my company is running is made up of data pipelines and machine learning pipelines. So we have a lot of infrequent jobs that don't really care about latency.

That sounds like a job for Fargate or EC2 instances that are managed by EC2 Capacity Providers on ECS.

Re: Behind the scenes, AWS Lambda

#85

Post by ignoramous »

cinquemb wrote: post #70
ignoramous wrote: post #51

Earlier quoted context omitted.

It may be product positioning, but Lambda really stems from AWS desire to do something about the dismal utilisation ratio of their most expensive bill item: Servers [0]. I speculate, 1min or 15mins workloads are optimum to schedule and run uncorrelated workloads. Any more, and it may diminish returns? [0] https://youtu.be/dInADzgCI-s?t=524 (James Hamilton, 2013)

I loved using spot instances for managing scaling for a startup i worked at, saved alot of money instead of using these services they provide.

I find myself favour Serverless more while it continues to mature, and generally have fewer complaints.

Btw, you'd like AWS Batch: It is a hassle-free, zero-code way to run batch / uncritical workloads on Spots. https://aws.amazon.com/ec2/spot/use-case/batch/

Re: Behind the scenes, AWS Lambda

#86

Post by rejectedandsad »

valenterry wrote: post #83
rejectedandsad wrote: post #80

Earlier quoted context omitted.

Given most things are frontended by API Gateway anyway this isn’t too big of a concern since there’s already an effective 30 second timeout there. For ETL like stuff you can use Stepfunctions too.

It's still sad, because then you need a lambda for just these one or two things that might run long (or maybe even forever) and now you have to mix lambda and e.g. ECS.

That's fair, if you do need a sort of long running connection for most Websocket tasks (there is the websocket/ApiGW hook but that's less useful), WebRTC, raw sockets etc there is no choice than to use ECS or something similar.

Re: Behind the scenes, AWS Lambda

#87

Post by ec109685 »

dilyevsky wrote: post #28
ec109685 wrote: post #18

Earlier quoted context omitted.

This is a good paper that talks about Aurora and provides some insight into how RDS operates: https://www.allthingsdistributed.com/files/p1041-verbitski.p... It’s nice that AWS builds their own higher level abstractions on the same primitives outside developers use. Feels like they eat their own dogfood much more than Google where they bypass GCP and instead utilize underlying Borg primitives for many services.

Which gcp services run directly on borg? My understanding is at least bigtable, cloud sql and other dbs are within “hidden” VMs. I think loadbalancers and storage are exceptions but same is true for aws (except the classic elb probably)

An AWS engineer talks about this here: https://twitter.com/rakyll/status/1415170934609121285?s=20

Re: Behind the scenes, AWS Lambda

#88

Post by ec109685 »

dilyevsky wrote: post #28
ec109685 wrote: post #18

Earlier quoted context omitted.

This is a good paper that talks about Aurora and provides some insight into how RDS operates: https://www.allthingsdistributed.com/files/p1041-verbitski.p... It’s nice that AWS builds their own higher level abstractions on the same primitives outside developers use. Feels like they eat their own dogfood much more than Google where they bypass GCP and instead utilize underlying Borg primitives for many services.

Which gcp services run directly on borg? My understanding is at least bigtable, cloud sql and other dbs are within “hidden” VMs. I think loadbalancers and storage are exceptions but same is true for aws (except the classic elb probably)

Other thing AWS has going in its favor is the rest of Amazon uses AWS versus at Google, none of their flagship services run on GCP (though I think YouTube is moving, which is good).

Re: Behind the scenes, AWS Lambda

#89

Post by dilyevsky »

ec109685 wrote: post #88
dilyevsky wrote: post #28

Earlier quoted context omitted.

Which gcp services run directly on borg? My understanding is at least bigtable, cloud sql and other dbs are within “hidden” VMs. I think loadbalancers and storage are exceptions but same is true for aws (except the classic elb probably)

Other thing AWS has going in its favor is the rest of Amazon uses AWS versus at Google, none of their flagship services run on GCP (though I think YouTube is moving, which is good).

The rest of amazon doesn’t run on aws in its entirety afaik. Also not sure it’s necessarily a good thing either.
Post reply on HN