Let’s start by creating the serverless project:

serverless create --template aws-python3 --path sqs-lambda-tutorial

cd sqs-lambda-tutorial

At this point, we can configure the serverless.yml and handler.py files. The code can be found in the following GitHub repo.

This yml file configures our functions, permissions and SQS resource.

This is where our code runs. It contains two functions. Each function represents a different AWS Lambda function. One will be triggered manually, and the other one will be triggered by an SQS message.

We will compare the SQS Lambda and the manual Lambda.

Deploy!

This is the magic of Lambda. Just run the following command while you are in the same folder as serverless.yml :

sls deploy

The output should look roughly like this:

Now we can invoke the “start” function by running the following commands:

sls invoke -f start-lambda

sls logs -f start-lambda

sls logs -f end-lambda

You will be able to see the CloudWatch Logs of the Lambda functions with the SQS message.

We are done. Congrats! ⚡️ Event Structure If you plan to use SQS in your application, you will need the event structure and data. You can find it in the following Gist.

SQS vs. SNS When applied to Lambda only, this is a tough call. Up to this moment, only SNS supported triggering Lambda functions. Now both SNS and SQS can trigger. Let’s compare the relevant parameters for Serverless applications: The main advantage of SQS is batch messaging, which can also lead to cost reduction. Performance Analysis: Serverless and SQS Distributing messages between services can be complicated. Understanding the performance impact on our applications is almost impossible. At Epsagon, we love to see the bigger picture for highly distributed applications. In a previous post, we compared several methods of distributing messages between functions (direct sync invocation, direct async invocation, SNS and Kinesis), and now, using our serverless performance monitoring tool, it’s a great time to introduce the results for SQS: