ASP.NET Core Serverless on AWS Lambda

Serverless

Serverless is on everyone's lips; in the .NET area it means mainly Azure Functions. In principle Serverless is all about not having to worry about scaling yourself - and that is much more than just Azure Functions.

However, it stops when you want to develop with ASP.NET Core; for example, a web page or an API. Basically everywhere you have to select a web instance or a docker container and choose a fixed scaling in the form of CPU, RAM and IO - serverless is not possible.

Serverless leading: AWS

AWS has now developed its own extension that makes it possible to run ASP.NET Core in a serverless environment! The AWS Toolkit for Visual Studio provides a corresponding template.

This template now creates an ASP.NET core project as usual - but directly with built-in serverless specialties from AWS.

The aws-lambda-tools-defaults as well as the serverless.template are the most obvious ones. While the tools-defaults are important for publishing from Visual Studio (where the target resources are specified, so it's an optional file), the serverless.template is the more important file.

Without knowing exactly how AWS managed to make ASP.NET Core run in a serverless environment, you can see here that it is a lambda environment and that some properties like MemorySize and Co are stored here.

{
    "AWSTemplateFormatVersion" : "2010-09-09",
    "Transform" : "AWS::Serverless-2016-10-31",
    "Description" : "An AWS Serverless Application that uses the ASP.NET Core framework running in Amazon Lambda.",

    "Parameters" : {
    },

    "Conditions" : {
    },

    "Resources" : {

        "AspNetCoreFunction" : {
            "Type" : "AWS::Serverless::Function",
            "Properties": {
                "Handler": "AWSServerless::AWSServerless.LambdaEntryPoint::FunctionHandlerAsync",
                "Runtime": "dotnetcore2.1",
                "CodeUri": "",
                "MemorySize": 512,
                "Timeout": 30,
                "Role": null,
                "Policies": [ "AWSLambdaFullAccess" ],
                "Environment" : {
                    "Variables" : {
                    }
                },
                "Events": {
                    "ProxyResource": {
                        "Type": "Api",
                        "Properties": {
                            "Path": "/{proxy+}",
                            "Method": "ANY"
                        }
                    },
                    "RootResource": {
                        "Type": "Api",
                        "Properties": {
                            "Path": "/",
                            "Method": "ANY"
                        }
                    }
                }
            }   
        }
    },

    "Outputs" : {
        "ApiURL" : {
            "Description" : "API endpoint URL for Prod environment",
            "Value" : { "Fn::Sub" : "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/" }
        }
    }
}

Lambda will also be informed at this point which runtime is necessary. It is therefore the description file how our serverless ASP.NET Core application has to be executed or started.

Apart from that it is only noticeable at this point that there is no Program.cs file, but two EntryPoint.cs files.

One starts our application on our local machine (LocalEntryPoint), the other in the Lambda environment (LamdaEntryPoint).

LocalEntryPoint.cs

namespace AWSServerless
{
    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();
    }
}

LamdaEntryPoint.cs

namespace AWSServerless
{
    /// <summary>
    /// This class extends from APIGatewayProxyFunction which contains the method FunctionHandlerAsync which is the 
    /// actual Lambda function entry point. The Lambda handler field should be set to
    /// 
    /// AWSServerless::AWSServerless.LambdaEntryPoint::FunctionHandlerAsync
    /// </summary>
    public class LambdaEntryPoint :
        // When using an ELB's Application Load Balancer as the event source change 
        // the base class to Amazon.Lambda.AspNetCoreServer.ApplicationLoadBalancerFunction
        Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction
    {
        /// <summary>
        /// The builder has configuration, logging and Amazon API Gateway already configured. The startup class
        /// needs to be configured in this method using the UseStartup<>() method.
        /// </summary>
        /// <param name="builder"></param>
        protected override void Init(IWebHostBuilder builder)
        {
            builder
                .UseStartup<Startup>();
        }
    }
}

With the help of right-click publish, we can simply publish the application on AWS here.

This only takes a few seconds.

Now you can simply request the ASP.NET Core Serverless application on AWS.

So here we see the standard welcome page of an AWS ASP.NET core application - in a Lambda environment. Completely serverless!

But...

... is the serverless application now restarted every time, or do we really have a stateful behavior like we are used to from any other ASP.NET Core Runtime? Let's give it a try!

For this I simply created a controller that remembers the time at the first call and should display the current time at each further call.

using System;
using Microsoft.AspNetCore.Mvc;

namespace AWSServerless.Controllers
{
    [Route("hello")]
    public class HelloController : Controller
    {
        public static DateTime Cached = DateTime.Now;

        public IActionResult Index()
        {
            dynamic output = new
            {
                Servername = Environment.MachineName,
                Current = DateTime.UtcNow,
                Cached = Cached
            };
            return Ok(output);
        }
    }
}

If the application now works as usual, then we always expect the current time (hence the name) at the current time (Current) and we expect absolutely no change at the cached time (Cached). A restart with every request would also provide Cached with the current time each time.

Tada! It works as intended! The cached time does not change, which means we have a real Stateful ASP.NET core environment!

Output on AWS Lambda:

{
    "servername":"169",
    "current":"2019-07-18T16:09:42.1432922Z",
    "cached":"2019-07-18T16:09:36.0130443+00:00"
}

Conclusion:

AWS has currently created something completely unique here: ASP.NET Core in a serverless environment. It works ingeniously well!

I still hope for a variety of technologies, so that we will see this ingenious implementation in other environments as well.