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

61–70 of 89 posts

Re: Behind the scenes, AWS Lambda

#61

Post by cloakandswagger »

mdaniel wrote: post #54
cloakandswagger wrote: post #31

Earlier quoted context omitted.

I can't think of any reason outside of product positioning. A lot of the novelty of Lambda is its identity as a function: small units of execution run on-demand. A Lambda that can run perpetually is made redundant by EC2, and the opinionated time limit informs a lot of design.

> A Lambda that can run perpetually is made redundant by EC2 Is only conceptually true outside of "EC2 Classic", because (to the best of my knowledge) every other EC2 launches into a VPC, even if it's the default one for the account per region, and even then into the default security group (and one must specify the IDs). That may sound like "yeah, yeah" but is a level of moving parts that Lambda doesn't require a con…

Lambda does provide a level of convenience via abstraction that EC2 doesn't: just provide inline code, an S3 hosted zip file or, recently, an ECR image and it's off and running.

I doubt this is a difference marker for most medium to large sized customers though. Making a wrapper for invoking uploaded code is trivial and if done on EC2 doesn't come with the baggage of Lambda (cold starts, costlier expense, more challenging logging and debugging, lack of operational visibility, etc)

Re: Behind the scenes, AWS Lambda

#62

Post by j4ah4n »

throwaway3699 wrote: post #20
nuclearnice3 wrote: post #14

Earlier quoted context omitted.

We surely picked up some baggage. Much of it vendor specific. But also we jettison some? You stick a lambda into API gateway and you're on the internet. No servers. No linux setup. No apache conf. I'd encourage you to dive in for 20 hours in pure curiosity mode and see what you find.

Lambda is a proprietary solution that only works for people on AWS. Linux is open, and I just need to put it on a box. How do I install the AWS Lambda stack on a standard Linux box?

Perhaps a different road to the same problem but on K8s it’s really simple to install a FaaS (e.g., Kubeless and others) provider and get the same benefits. Different metrics sure, but the approach to getting deployable runtimes is the same (if using Serverless framework for example).

Of course then you need a cluster which may be back at AWS as EKS (or not) but at least it’s more open from that perspective.

Re: Behind the scenes, AWS Lambda

#63

Post by valenterry »

rejectedandsad wrote: post #32
abarrak wrote: post #25

Earlier quoted context omitted.

Nice. I wonder if the stateful merits provided and marketed by containers orchestrates (e.g. K8S) is something they will consider in the future? ..

To build a new service at Amazon, the general path of least resistance these days is to use Lambda. If not Lambda, then ECS. If not ECS (or if it requires bare metal) then EC2.

Yeah, except for the lambda time limit...

Re: Behind the scenes, AWS Lambda

#64

Post by ben0x539 »

Something1234 wrote: post #50

Fantastic paper. So I've been playing with the java and python runtimes and it's absolutely stunning how much better python is on execution and start up time. Also how does an event actually get to the lambda handler? Because they can come from all kind of sources.

Judging from five minutes of browsing the go runtime sources, they poll some lambda API:

https://github.com/aws/aws-lambda-go/blob/159d1c69878562cd54...

The response is apparently posted to another API endpoint.

Googling for the environment variable actually specifying the API endpoint, I found https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom... which seems to spell out some of the details.

Of course that just moves the question to "where does the runtime API get the event from?" but at that point they could be doing all kinds of things, I guess.

Now I'm curious to see what happens if you ask for more events before returning a response for the first event you got. Can you actually process events in parallel?

Re: Behind the scenes, AWS Lambda

#65

Post by a-dub »

i keep seeing talk about fast firecracker boot times... but as far as i can tell firecracker is something that talks to the KVM apis and does monitoring...

wouldn't fast boot times be a result of kvm and the structure of the VM being booted, or does this boot time metric include scheduling (on one or more firecracker hosts) and delivery of the image to the runner host for the VM?

Re: Behind the scenes, AWS Lambda

#66

Post by otterley »

simonw wrote: post #29
kolanos wrote: post #22

Earlier quoted context omitted.

This service exists, it's called AWS Fargate [0]. [0]: https://read.iopipe.com/how-far-out-is-aws-fargate-a2409d2f9...

Fargate isn't a competitor to Cloud Run (I wish it was) because it doesn't scale to zero in between requests and scale back up again when new traffic arrives.

Check out AWS App Runner. It may do exactly what you’re looking for.

Re: Behind the scenes, AWS Lambda

#67

Post by bigodanktime »

Something1234 wrote: post #50

Fantastic paper. So I've been playing with the java and python runtimes and it's absolutely stunning how much better python is on execution and start up time. Also how does an event actually get to the lambda handler? Because they can come from all kind of sources.

Pretty sure its just gRPC calls, and firecracker passes events along to its firecracker-containerd services.

My guess is java is slow as it works really well when the JIT can optimize your code. Longer running functions will very likely outperform python.

Re: Behind the scenes, AWS Lambda

#68

Post by bigodanktime »

Lots of interesting work is being done in this area (Currently doing research around serverless at the moment). Cold start up times still remain a pretty large issue (125ms start up for VM is still quite large) but some interesting papers trying to attack this, through strategies like snapshotting!

https://arxiv.org/pdf/2101.09355.pdf

Also predicting function calls to properly schedule and reduce cold start latency

https://www.usenix.org/system/files/atc20-shahrad.pdf

Re: Behind the scenes, AWS Lambda

#69

Post by mcspiff »

daxfohl wrote: post #44

One other thing I learned here is that lambda@edge is not actually run on the edge at all. It is forwarded to the nearest datacenter to execute. Not enough capacity in edges to spin up entire VMs for everything, even with Firecracker.

They do have Cloudfront Functions now for real Edge compute: https://aws.amazon.com/blogs/aws/introducing-cloudfront-func...

Re: Behind the scenes, AWS Lambda

#70

Post by cinquemb »

ignoramous wrote: post #51
cloakandswagger wrote: post #31

Earlier quoted context omitted.

I can't think of any reason outside of product positioning. A lot of the novelty of Lambda is its identity as a function: small units of execution run on-demand. A Lambda that can run perpetually is made redundant by EC2, and the opinionated time limit informs a lot of design.

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.
Post reply on HN