Managing AWS Lambda Functions using dotnet core 2.0 and Terraform

Question

Setup

• VS Code
• Terraform (v0.11)

Problem

I'm having difficulty understanding how to manage Lambda Functions in a dotnet core 2.0 project

Current Approach (not implemented just how I think it could work)

• Create the Function structure in Terraform
• Create the Function code in a dotnet core project, as described here
• Zip the publish folder and upload to S3
• Reference the Handler for the Function in the Terraform Function definition as per the AWS documentation for c# (assembly::namespace.class-name::method-name)

Terraform Lambda Function Example

resource "aws_lambda_function" "this" {
  function_name = "test_function"
  role          = "lambda_exec_role"
  s3_bucket     = "my_bucket"
  s3_key        = "object_key/package.zip"

  handler = "MyApp::Example.Hello::MyHandler"
  runtime = "dotnetcore2.0"
}

This approach means that if I change a single function in a project, I have to upload the entire code base to S3 which doesn't feel like a clean way to handle code changes.

Alternative Approach

• Use the dotnet core CLI to manage Lambda Functions instead of Terraform
• Deploy each function using the dotnet core CLI dotnet lambda deploy-function

This approach feel cleaner from a Lambda code version management perspective, but it means that I'm no longer using Terraform to manage my Lambda Functions.

I've used NodeJs and Go to create Lambda functions before, each seems more lightweight than the dotnet approach (in that it's easier to de-couple each functions source code).

Question

Do either of these setups appear optimal?

Answer 1

I'm aware the question was asked around a year ago from this response, so I don't know how much everything has changed since then, but this is what has worked for me:

I started using the dotnet CLI Lambda tools, just like you suggested, and it works just fine. It works out of the box and it requires minimum configuration. The problem I encountered is that I needed to set up some specific configuration which Cloudformation didn't allow. That's when I started leveraging Terraform. After some digging, I decided to go with Terraform because it fixed this issue.

Now, you mentioned how the pitfall of using Terraform is that you have to upload the whole code to S3... but I have found that the dotnet CLI tools do exactly the same. If you checkout the output of executing dotnet lambda deploy-function you will see:

Zipping publish folder
... zipping: some.dll
... zipping: another.dll
Created publish archive (---)
Uploading to S3. (Bucket: ---)
... Progress: 11%
... Progress: 55%
... Progress: 100%
Creating new Lambda function some_lambda

So, in a nutshell, I've decided to stick to Terraform and simply elaborate a custom shell script which first runs dotnet restore, then dotnet build and lastly terraform apply. And that's all I need to deploy my application to AWS. I find this a more customisable approach than using Serverless of Cloudformation with the dotnet CLI.

I hope that helped!