Видео

Hey good question! It's because the size of your bundle directly impacts your cold start latency for serverless functions! I gave a whole talk on this at AWS re:Invent: ruclips.net/video/2EDNcPvR45w/видео.html

Less code (assuming it's still doing similar work) will generally run faster than more code as it can take better advantage of CPU cache etc, "Locality of Reference" is a term to search further on the subject. JS is an interpreted language so less code to interpret also means faster startup times which is especially important on hosting platforms like "lambda" that can scale to zero

Yeah it's awesome!

Sure thing, glad you enjoyed it!

Thanks! Yeah Hono has really hit something special here, I think it's doing a lot of the things we initially sought to do on the Serverless Framework which fell off after focus shifts revenue challenges.

Hey! not really, but I'm happy to answer any specific questions. You can DM me on twitter

Thanks Nacho!!

Thanks Ryan!!

No problem! You can run it on a regular VM but you'll need to set up the AWS Lambda Runtime Emulator as well

Your comment is entirely indecipherable so I won't bother, but if you think I'm confused about how lambda functions work, you may want to look me up.

Why would you use api gateway instead of raw lambda?

@@maratmkhitaryan9723 Oh tons of reasons, I wrote a whole post about the difference between mono-lambda APIs versus single function (routing in APIGW) APIs: aaronstuyvenberg.com/posts/monolambda-vs-individual-function-api

Thanks so much!!

haha yeah your database can absolutely lock you in, no question about it

@@tcurdt that's my point, if the service is expensive you can deploy the same application somewhere else cheaper with no code changes.

@@astuyve My point is: dependencies on services is what create the real lock-in.

@@tcurdt I'm not sure you're making a cogent point. I've just demonstrated how you can have no dependency on any one service. You can build an application and deploy it to Lambda, Fargate, Coolify, k8s on oracle - literally anywhere. If the service charges too much, just leave. The real lock in is at the database (if you store everything in say - dynamoDB)

@@astuyve You can't run the lambda without storing state somewhere. Or if you have something more sophisticated, you will be teased to use some of the AWS managed products. Especially ones that have proprietary protocols in use. RDS, S3, are examples of protocols that you can use in nearly any other cloud. But there also are many other AWS products with proprietary protocols, which will not allow your app to move to other cloud.

​@@maratmkhitaryan9723 I think that's mostly true. There's a higher bar for interop with something like MongoDB or Spanner and DynamoDB (for example). But a ton of people are still simply using SQL, and now with egress fees waived from AWS if you're moving to another cloud, you've never been less locked in.

@@bear_jaws exactly

Hey good questions but not quite correct. Firstly, the Lambda Web Adapter doesn't require you to use a container, I just did because that makes it easier to test it elsewhere. You can ship a zip function this way. However there's no downside to using a container in Lambda. You can use the exact same base image that AWS uses for Lambda, they publish it even before it makes it to the Lambda runtime itself. I'm not sure what you meant by performing well under load but based on the evidence I've collected that is not the case, the container is irrelevant because it's not actually running in Lambda (it's simply a packaging mechanism). Finally, containers have much faster cold starts now - in many cases even faster than zip functions. I wrote a long blog post about it, which you may have seen: aaronstuyvenberg.com/posts/containers-on-lambda

@@astuyve great blog post, and glad they've improved cold starts. The issue I had under load was with unstable connection pooling via aws-sdk following hibernation when trying to invoke downstream services in any significant quantity. I just had noticeably higher request latency (I was invoking another function). I don't know if this was due to the container I was using, or due to the bundled aws-sdk that's optimised for lambda, or both. Deployment speed was an issue too from memory, what was it like when you tested in Jan?

@@origanami Again the container part is simply a deploy time packaging mechanism. Your code is fully extracted into s3 after you deploy a container to Lambda (yeah, that part is slower than zip, but it's up to 10gb so the increased size is fair IMHO). We run a few thousand functions continuously to verify our implementations across runtimes and at a quick glance I haven't found any discrepancy between container-based functions and zip-based functions when it comes to performing a direct lambda-to-lambda invocation. I'm not sure what the cause of the issue you saw is, but I'm not able to replicate it myself.

@@anthonytrad less than you'd think! Container images have come a long way in Lambda, I did another video about how they made them so fast ruclips.net/video/qAYY9df2hVQ/видео.htmlsi=oPfCPAQzmxceNJ3I The web adapter does introduce a bit of overhead but it's a pretty tiny binary overall

Thanks!!!

Thanks!!

@@banafish thanks so much!

absolutely insane - AND it still makes for a pretty good firewall toolkit too

They went so far optimizing the engine for packet filtering that they discovered the virtual machine for the DSL could be used for any other high performance filtering in-kernel 😂

ok

you didn't put first :(

@@HeRvAsH93 zero dollars and zero cents, all of this is well within the AWS free tier limits

Thanks for the kind words! I'm happy to do that, we create a ton of functions from scratch all the time

Thanks! I'll try to fix the mix. I always ask chat when I start how the audio is, but will adjust further.

Yoooo thank you!

LMAO

I agree, but mostly for the sake of curiosity. I'm not sure what actionable insight we'd get from that information, but it would be interesting!

So glad you enjoyed it! Definitely avoid using Lambda Layers (with a few exceptions). I did another video on this

I swing by proactively every now and then, as a preventative measure.

Hey! Great question. 1250 is the new maximum number of concurrent invocations consuming from one queue, you can find that limit in the new announcement blog for faster scaling (aws.amazon.com/blogs/compute/introducing-faster-polling-scale-up-for-aws-lambda-functions-configured-with-amazon-sqs/) as well as the docs. I'd suggest increasing the batch size so each invocation receives more messages, and then increasing the RAM and optimizing the function code to process multiple messages at a time. Good luck!

Thank you so much for the kind words, it means a lot and I sincerely appreciate it!

crazy how often that seems to be the case!!

Exactly! Super simple, instantly boosts performance by ~5x or more.

Thanks, glad you're enjoying it!

Hey! Yeah great question. If the failure isn't temporary you'll of course need some kind of fatal-handling system. If I don't expect to re-drive messages, I usually just set a max attempts value and then write them to logs on the last attempt.

Thank you for the reply!@@astuyve Do you mind elaborating how would you set a max attempts value? (If you push the records back into the queue using partial batch response, is it possible to include some kind of attempt number?) I am new to Lambda and SQS and really appreciate the content you're putting out!

Hey! AWS tracks that for you, so you simply have to mark the messageId in the batchItemFailures response and SQS will keep track of the number of attempts for that message. No need to change anything in your own code besides the example I've shown here. Glad you are enjoying it, and good luck on your learning journey!

Thanks for the kind words! My biggest concern in your case is safe deployments. Unless you're using Lambda versions + aliases, you'll be unable to add/update a dependency without fully backwards compatible code without risking Lambda errors for at least a few seconds because the updateFunction and updateFunctionConfiguration API calls are asynchronous. When I ran into this with Vercel, those functions errors out for about 6 seconds until both operations were complete. This can be avoided with aliasing, but you still risk dependency smashing. Either way, I hope you use what works best for you. Good luck!

@astuyve Wow, very interesting, that's definitely good to know! Yes we are using versions and aliases because of provisioned concurrency which is required is, so we set is as a basic requirement for a stack. By the way, have you encountered issues where, even though provisioned concurrency is configured, Lambdas still experience cold starts? This happens even with regular traffic, not just bursts. It’s something that occurs quite randomly for us, and we can't find the root cause… Also we recently started using Datadog for serverless applications and are really excited about it. 😊

@@MatanCohen-Abravanel Glad you're liking the product! Yes I've seen this happen with Provisioned Concurrency even with regular traffic, as ever so slightly (occasionally) there are no warm instances to serve the function. I'd check the lambda concurrency metric to see if you're bumping close to your PC value. If that function is nowhere near the provisioned capacity, I'd probably open a bug with AWS and ask.

Thanks!!

Thanks so much Aaron!!