Are Lambda-to-Lambda calls really so bad?

Amazon Web Services Feed
Are Lambda-to-Lambda calls really so bad?

If you utter the words “I call a Lambda function from another Lambda function” you might receive a bunch of raised eyebrows. It’s generally frowned up for some good reasons, but as with most things, there are nuances to this discussion.

In most cases, a Lambda function is an implementation detail and shouldn’t be exposed as the system’s API. Instead, they should be fronted with something, such as API Gateway for HTTP APIs or an SNS topic for event processing systems. This allows you to make implementation changes later without impacting the external-facing contract of your system.

Maybe you started off with a single Lambda function, but as the system grows you decide to split the logic into multiple functions. Or maybe the throughput of your system has reached such a level that it makes more economical sense to move the code into ECS/EC2 instead. These changes shouldn’t affect how your consumers interact with your system.

But what if the caller and callee functions are both inside the same service? In which case, the whole “breaking the abstraction layer” thing is not an issue. Are Lambda-to-Lambda calls OK then?

It depends. There’s still an issue of efficiency to consider.

If you’re invoking another Lambda function synchronously (i.e. when InvocationType is RequestResponse ) then you’re paying for extra invocation time and cost:

• There is latency overhead for calling the 2nd function, especially when a cold start is involved. This impacts the end-to-end latency.
• The 2nd Lambda invocation carries an extra cost for the invocation request.
• Since Lambda durations are paid in 100ms blocks, so you will pay for the amount of “roll-up” time for both caller and callee functions.
• You will pay for the idle wait time while the caller function waits for a response from the callee.

While the extra cost might be negligible in most cases, the extra latency is usually undesirable, especially for user-facing APIs.

If you care about either, then you should combine the two functions into one. You can still achieve separation of concerns and modularity at the code level. You don’t have to split them into multiple Lambda functions.

But, if the goal is to offload some work so the calling function can return earlier then I don’t see anything wrong with that. That is, assuming both functions are part of the same service.

Don’t forget to configure a DLQ or an on-failure destination for the callee function. As a rule of thumb, you should ALWAYS have a DLQ or on-failure destination for any async functions. (thanks for Sara Gerion for bringing this up)

Also, you may still put something between these two functions to regular concurrency. For example, using SQS or Kinesis to allow these tasks to be processed in batches and to smooth out traffic spikes. This is especially important when dealing with downstream systems that aren’t as scalable as Lambda. In which case, use Lambda’s scaling behaviour with other event sources to regulate the concurrency of the callee function.

So, to answer the question posed by the title of this post – it depends! And to help you decide, here’s a decision tree for when you should considering calling a Lambda function directly from another.

Hi, my name is Yan Cui. I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

You can contact me via Email, Twitter and LinkedIn.

Hire me.

The post Are Lambda-to-Lambda calls really so bad? appeared first on theburningmonk.com.