Deploy RESTful API with net framework 4 5 in AWS Lambda

Question

What could be the possible issues, I may face when trying to migrate an existing API developed in .NET framework 4.5 and deployed in an IIS to a serverless architecture based on AWS Lambda.

Currently, the API is divided in: 

• Controller (entry point) 
• Service (buz logic) 
• Repository (basically LINQ) 
• DTO and DAO's. 

In addition, there are some dependencies to external libraries but I don't know if that really matters.

Main Concern:  As I could see when configuring my Lambda, it only accepts .Net Core applications. Then, is it necessary to migrate to .Net Core? If it is, can anyone tell me how much development that requires considering my set up?

Answer 1

It is highly important to pay specific attention to the dependencies to external libraries, because they are required to support .NET core and might add a substantial load time to your lambda function.

If you have an existing .NET API developed in 4.5, it is advisible you try to migrate the whole API. Lambda's pay-for-what-you-use model is  largely incompatible with ASP.NET MVC/WebApi's server model.

Answer 2

Is it necessary to migrate to .Net Core?

Yes, as Lambda runs on Linux.

If it is, can anyone tell me how much development that requires considering my set up?

You will need to pay specific attention to the dependencies to external libraries, as they need to support .NET core and might add a substantial load time to your lambda function.

If you have an existing .NET API developed in 4.5, I would strongly advise against trying to migrate the whole API. Lambda's pay-for-what-you-use model is very attractive, but largely incompatible with ASP.NET MVC/WebApi's server model.

Answer 3

This is an old question (somewhat), but I'll add my 2 cents:

First - AWS Lambda functions run in Linux containers under the hood, and currently support .NET Core 2.2.  So you would have to port your code to .NET Core. However, .NET Core 2.2 implements the .NET Standard 2.0 APIs, so if you're not making use of Windows-only libraries (manipulating images, for instance), and instead doing mostly CRUD operations, it may not be so difficult. You can use the .NET Portability Analyzer (free from Microsoft) to analyze your solution to see how much code would need to be refactored.

As someone else pointed out, the dependencies on 3rd-party libraries could be a problem, if those libraries don't adhere to the .NET Standard 2.0 standard (or at least, if the functions you use in them use APIs not in .NET Standard 2.0).  The portability analyzer can check those DLLs also (it works against binaries). 

As a general strategy, for a Web API project to Lambda, I'd suggest carving off individual APIs at a time, implementing them as ASP.NET Core Web APIs (with either a single controller, or a small number) per Lambda, to keep the Lambda size small (improves start-up times).  If your repository code is talking to a relational database (ie, SQL Server), you'll either need to have your database be publicly accessible (not recommended) or run your Lambda function in a VPC (where it gets its own IP address), which means cold-start times will be even slower.  However, you there are ways to keep Lambda containers "warm" (using CloudWatch events, for example).

I have deployed basic ASP.NET Core MVC and Web API projects both to AWS Lambda, but I started them out in .NET Core. As a way to start, try creating a new ASP.NET Core Web API project using the AWS Toolkit for Visual Studio (an extension), using the project types under "Lambda", and choosing "Serverless application", then picking the Web API template. This will also create the API Gateway API, and associate it with your Lambda, when you deploy it.