AWS Lambda002: Triggers and Destinations
Tags: cloud, aws, serverless, lambda
Published: 2020-03-16 10:36:43


AWS Lambda is a great invention that saw the light in 2014. It follows the pattern of event-driven, which means that if an action happens, a response will be processed and presented for the entity that triggered this event, either a person or a machine.
This leads me to the point of this article, triggers, and destinations that AWS Lambda works with. I will make another article to describe the ‘doing’ part for these triggers and destinations. So, shall we begin?

#Triggers:

Triggers are the events that trigger Lambda, straight forward description, correct?
But, what are the type of triggers that invoke Lambda? Let’s explore the options:

__Lambda Reads Events:__

Lambda can read messages from certain services. These services are generating queues that pass the messages to the function in both execution ways, synchronous and asynchronous.

When the function gets triggered synchronously, the message provider service will wait for a reply from Lambda. In case of a failure, you have the option to activate retry on error, which will retry to execute the function with the same message. The reason for that retry is at some point, you might face a timeout from the function, DB connection or any other service.

This execution type is great for data streaming functions. Because when we talk about the services that serve this execution type, which are Kinesis, DynamoDB, and SQS, we notice that all these services are made to batch data at a steady level. Also, as you might notice, reading events can execute the function in both ways, which is an advantage that can serve the main task from Lambda by executing in that way!

__Lambda and synchronous execution:__

So, as you know by now is that Lambda can be triggered synchronously. How that’s happening?

Imagine you’re in a bakery, and by the time you reached the baker, you asked him for bread. You will wait till the baker returns with the bread, you’ll pay and leave. This is a synchronous action that you’ve made.
Lambda gets requests from the following list and performs synchronous execution for:

- Elastic Load Balancer.
- Cognito
- Lex
- Alexa
- API Gateway
- CloudFront
- Kinesis Data Firehose
- Step Functions
- S3 Batch

Let’s talk more about API Gateway since it’s one of the most common use cases in this list.

You as a user called an endpoint. This endpoint has a defined inner destination, which is in our situation is Lambda, API Gateway will wait for the Lambda to finish the execution and return a status code along with or without a body to return it to the API Gateway consumer.
Note:
API Gateway execution limit is 30 seconds. So, if you have functions that take more than this specified time, consider the next paragraph option.

__Lambda and Asynchronous execution:__

We talked in brief about the synchronous execution. Now, let’s have a word about the other execution type, Asynchronous execution.

A real-world example is texting, when you text someone in Whatsapp, you’re technically not blocked. The reply might take seconds, minutes or even hours. The action in this situation is sending the text message and the reply is Asynchronous. I hope you got the point.

What are the services that can trigger Lambda Asynchronously?

- S3
- SNS
- SES
- CloudFormation
- CloudWatch (logs / events)
- CodeCommit
- Config
- IoT / IoT Events
- CodePipeline

Now, let’s talk about an example that occurs by a service, S3. Imagine you’ve setup a notification trigger that when a new Put request performed in X bucket, this will trigger Lambda to get metadata and will create a thumbnail if the uploaded file is an image. This action will happen in the background and thumbnail creation won’t block you or you’re expecting to get a link of this file.

#Destinations:

Destination is the functionality that you can setup if you need extra steps in your function. These functions are triggered based on a defined status like in case of success, trigger this Lambda function to perform x action.

Lambda Destination is a way that Lambda can perform extra steps that gives you more visibility and simplify event-driven processes.

To make things clearer, Lambda Destination is an extra optional step that you define if needed. Also, make sure you understand that Destination is triggered Asynchronously only, which means that if the Lambda function got triggered synchronously or Asynchronously won’t affect the way that Destination works.

There are some services that can be triggered by Destination at the time this article was written.

- Lambda
- SNS
- SQS
- EventBridge

Why don’t we explain a real-world example?

Imagine you’re triggering Lambda via API Gateway, You’re expecting either to get success or failure message. You can add this extra step in both cases, which means that if the function succeeded, send the return to another Lambda and finish the processing or send it to an SQS in case of failure.

Hope that makes sense for you.

#Summary:

AWS Lambda has a lot of ways to get triggered that can serve the application needs. You can trigger it for short time processes that wait for reply or the function that can be triggered and left to work for longer period (max 15 min per function). As we discussed, there are three ways to trigger lambda and each one of them serves a need or follows an application pattern you decide. Also, Destination are an add-on point of processing that you can configure to work as Asynchronous to perform a status based actions.

In the next article, we will have some code examples for some use cases. Stay tuned for that.