Top 5 AWS Lambda Anti Patterns

[@BeABetterDev]

Like this video? Check out my course, AWS Lambda - A Practical Guide - www.udemy.com/course/aws-lambda-a-practical-guide/?referralCode=F6D1A50467E579C65372

[@JMa-cg1ks]

Can you chain lambdas if you don't expect a response?

[@СергейМонин-д7с]

I'd like to add a note about lambda batch processing: in some cases, message can fail over and over again. This can create an endless loop, so always use a dead letter queue with maxReceiveCount parameter.

[@BeABetterDev]

Great tip!

[@srinivasreddydanda1777]

Thanks a ton, Daniel!! I've learnt lot of AWS components from your channel. Especially lot of stuff around Lambda like this. Your playlists are super helpful & i've kept a target to watch at least one playlist of yours per week to complete 343 videos that you uploaded till date

[@BeABetterDev]

Thanks so much Srinivas! The 343 videos may take a while haha :D

[@shashank_rajak]

I am new to lambdas and I was going to design my lambda with the very first anti pattern, thanks for saving me haha

[@BeABetterDev]

You're very welcome!

[@Atpugtihsrah]

4:43 Are log streams really independent of the Lambda functions? In my experience, log streams are created, one for each lambda function.

[@Atpugtihsrah]

Great video. Thanks!

[@BeABetterDev]

You're welcome!

[@youngsea89]

your video content is AWS some! keep it up bro

[@djaniel4028]

hello. recently started working at the same place as you and finding it particularly helpful on your videos and its funny i could tell you worked at this place before i even checked due to the strong and obvious values presented. Thanks for the vids

[@BeABetterDev]

Thanks Djaniel. Glad this resonated with you and you find it helpful :)

[@madrag]

Would love to see episode on this lambda logging

[@princechhabra9342]

Thank you for making this video.. I learnt a lot from your AWS videos

[@pfrieden1]

Thanks for bringing up metrics from Lambda - I may need that soon!

[@BeABetterDev]

Happy to help Paul!

[@TheLostBijou]

BABD, you run an amazing channel. Thanks!

[@LeandroSantos-bt1lg]

Very helpful content.

[@BeABetterDev]

Glad it helped!

[@sercantor1]

great video I'm guilty of putting runtime exceptions and 5XX errors into the metric API, I'll look into creating a metricfilter to catch them for the alarms.

[@ighsight]

Excellent.

[@BeABetterDev]

Many thanks!

[@itsme1587]

Please please make some videos on real time projects, you have a huge experience on the serverless. Project will help us to grow fast

[@mandarkulkarni9525]

Do you have any solution video on Pitfall2. emitting line to cloud-watch and creating metric filter out of it. Would really appreciate it.

[@JamesSmith-cm7sg]

very good, thanks

[@vijethkashyap151]

What will be solution for Pitfall 3? If we have lambda synchronously tied up? What is the better approach to this?

[@karthikm3549]

Persist the state to database and do a call back.

[@jonzezk.4495]

For emitting metrics it’s much easier to use Embedded Metrics Format

[@BeABetterDev]

I've heard about this from peers but never tried it myself. Is it easy to set up and use?

[@natenez]

I was planning to say the same thing. Yes it is trivial to do, and Lamdba Powertools provides some extra features on top like cold start metrics

[@haakonness]

Thanks, I didn't know about this. This is so great!

[@roach_iam]

@@BeABetterDev Would love a video on this!

[@rickharold7884]

Good ones!

[@alejandrombc]

Why is it better to process batch instead of single lambda processing?. The only downfall I think might be the amount of invoked lambdas, but I think it keep the process more clean

[@cristiannechita2032]

One of the downside is scalability. In each region you can have only X lambdas running concurrently. If all of a sudden you have a huge influx of message you might hit the concurrency limit. You can keep the process clean when handling a batch of messages by splitting the handler function (which receives the messages) from the actual business logic processor.

[@BeABetterDev]

Basically what Cristian said is spot on. The other major factor is cost.

[@alejandrombc]

@@cristiannechita2032 thanks for the response!. But if you use sqs you will hit the concurrency limit, but no new event will be process from the queu right?. So when a lambda finish a new lambda will be triggered, so no message will be “lost”. Either way I get the point 👌. Also if you use batch, what if you have 1 event alone for a “long time”? it will not be process until you have the X amount of events? About pricing, is it really a factor?, if a lambda takes 2secs to process a message. What will be cheaper 5 parallel lambdas with 2sec each or 1 with 10 seconds? (The first scenario will be faster because of paralellism, but am not sure really). Thanks again for explaining me out the pitfall 🙌

[@СергейМонин-д7с]

Batch processing in some cases is more preferable, for example, when you need to process a bunch of URLs. So doing multiple requests in parallel such as axios.all is much efficient than doing single requests, such as axios.post or axios.get.

[@Atpugtihsrah]

For the last pitfall, another caveat would be: If your lambda function takes a lot of time in processing each SQS message, then it may take some time for the rest of your messages to be processed since it would be sequential iteration. Ex: Scenario 1: Each lambda processes 1 message each, so 5 messages and 5 lambda instances processing them in parallel. Each message take 10mins to run so everything done in 10-12mins (including invocation time). Scenario2: Each lambda processes 5 messages in a batch and then iterate over them processing them together. The whole flow will end up in 50-52mins so the last message will get processed in way more time here.

[@mnathan18]

Any alternative for such uses?

[@katearcher8881]

But in second case lambda will fail because max timeout is 15 minutes. Maybe you should use something else if you need process large chunks of data that take a long time. How about glue etl jobs?

[@seeingblind2]

*what what are you doing step-function?*

[@PankajSingh-kq2gj]

Wow!