Consuming NSB Messages in AWS Lambda Functions

Hi, we have a scenario where we may want to use aws lambdas to process messages from a SQS queue where the messages have been placed there by NServiceBus. To me that means that the lambda function would need to implement some of the functionality provided by using NSB e.g. if we need to reply then the lambda will need to interrogate the message header in order to discover the reply to address.
Also, lambdas appear to have a built in retry policy of two retries before sending the message to a dead letter queue. Although for this scenario we would be using SQS as the transport and would set up the DLQ on SQS.

Have you any advice on how using lambdas could be done? Does it even sound feasible?

Any help appreciated.

Hi,

Currently, NSB does not offer anything in the way of specific support for AWS Lambda.

The way I would do this it to write an NSB message handler specifically for the purpose of sending a message to AWS Lambda, to act as a kind of “gateway” to that non-NSB world. I.e. I would send a message to the NSB handler, and the handler would take a dependency on the native client libraries which are used for sending messages to AWS Lambda. The handler would have the single responsibility of sending a native AWS Lambda message.

As you say, you may, and probably will, end up having to re-build some significant parts of the infrastructure yourself which NSB normally provides for you. It may be worth considering whether AWS Lambda really is the best choice for processing those messages or whether it’s better to use NSB handlers.

Hi,

What we have customers already doing is using NServiceBus Sendonly endpoints in a Lambda Function. SendOnly endpoints by default are fairly quick to create and available for send operations since we are not creating any receiving infrastructure. One caveat though can be the assembly scanning. By default the assembly scanning is a bit eager to scan many things and that can contribute to the overall execution time of the lambda function. I would suggest you tweak the assembly scanning to your needs to speed up the cold start time of an endpoint by following our assembly scanning documentation

Hope that helps
Regards
Daniel

Thanks for the suggestions.