aws-lambda-dotnet VS LambdaSharp.Benchmark

I saw this issue: https://github.com/aws/aws-lambda-dotnet/issues/245

Creating Lambda Project using Amazon.Lambda.Templates. I use Amazon.Lambda.Annotations because it will be similar to my previous console program, and we can use dependency injection.

Hopefully, this post will have intrigued you enough to check out the new framework, and try converting some of your existing functions into what I think is a much more readable and easier to comprehend format. Also, the development team is always interested in feedback, which you can supply in the issues folder of their repo. You can also find the design document for the annotations in this issue.

I don't think it's exactly what you're looking for, but you could try out the LambdaTestTool https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

According to this GitHub issue we need to add and configure an additional package when running a custom runtime on ARM:

I'm assuming API's are REST APIs. Those sound like excellent use cases for running as Lambda functions. If the API's are an ASP .NET Core Web API project it is possible to deploy that to Lambda using the Amazon.Lambda.AspNetCoreServer, https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src/Amazon.Lambda.AspNetCoreServer, NuGet package. That can be a quick way to get something working and then later choose to rearchitect to a smaller more micro services architecture if necessary.

AWS provides a NuGet package (see Amazon.Lambda.AspNetCoreServer) that makes it easy to do this. It works pretty well, but instead of one copy of the API serving many clients you have many copies of the API each serving one client at a time. There are also limitations in areas like file upload and download (which vary depending upon whether this is being used with API Gateway or an Application Load Balancer).

The Minimal project defines a Lambda function that takes a stream and returns an empty response. It has no business logic and only includes required libraries. There is also no deserialization of a payload. This is the Lambda function with the least amount of overhead.

Unfortunately, we can't use the outstanding BenchmarkDotNet tool with AWS Lambda. So, I built a benchmarking harness to collect data for all the deployment options, and hopefully, determine an "optimal" combination.

In the next post, I'm going to dive into the lifecycle of an AWS Lambda instance and associated terminology. I'll then cover some of the compilation and runtime options for .NET code. Then I'll introduce the benchmarking methodology. Finally, I'll present my findings and conclusion. As with all studies, peer review and independent confirmation is critical. Therefore, all my code is also made available under a permissive open-source license in the LambdaSharp.Benchmark GitHub repository.