.NET Workloads on AWS Lambda

Before talking about serverless computing, let's cover traditional computing for a moment.

Many companies, both small and large, use on premises servers, or data center based servers, to run their applications. When these companies need more servers, they have to buy them, physically install them, configure them, secure them, and maintain them. (In some cases, a data center may take care of physically installing them on your behalf, but you still need to do the rest.)

When all this is done, the company can deploy their applications to those servers. For many companies, this can take weeks or months. These delays have traditionally made it difficult to scale applications.

Cloud computing has made much of this easier. A company can launch an instance of a server (or multiple instances) in minutes. The company can create their own machine images with the virtual machine and operating system configured just the way they want. This reduces the amount of configuration that is needed once the server launches, but they still need to keep the server up to date with patches, security updates, and software updates, etc.

In many cases, these servers are often kept running 24/7, even though they are not in use all this time. The servers are often provisioned to handle the peak workload the application expects to see. But outside of this peak, the servers are at least partially idle. Appropriate scaling policies can be used to reduce help with this problem, but this can be hard to get right.

Also, the work of provisioning & maintaining the servers, and the time the servers spend idle, leads to costs that are not directly benefiting the company.
An alternative to this is serverless computing. There are no servers, there is no maintenance, and scaling is handled for you. You write your code, deploy it, and let AWS handle the infrastructure for you.

AWS offers two options for serverless computing, AWS Fargate for container based applications, and AWS Lambda for event driven applications.

AWS Lambda is a serverless compute service that executes your code in response to events received by the service. Events can be generated by other AWS services, such as SNS, SQS, S3, DynamoDB, API Gateway, etc.

Using an API Gateway, or Lambda function URLs allows you to trigger a Lambda function to run in response to an HTTP request. Lambda functions can also be invoked directly, though this too is considered an event.

You do not need to provision any infrastructure to use AWS Lambda. AWS also takes care of automatically scaling to meet the needs of your application, whether that is a few executions per day, or tens of thousands per second. The Lambda infrastructure, managed by AWS, is highly available, and fault tolerant.

With Lambda functions you only pay for the compute resources you use. When your code is not running, you are not paying.

You write your .NET applications using the IDEs you are already familiar with, then with the help of AWS tooling (or an IaC of your choice), you deploy your application to AWS Lambda.

When a Lambda function is invoked by an event, an execution environment is created, your initialization code is run (constructors, etc), then your code to handle the event is run.

Once execution is complete, the execution environment remains available for reuse for a non-deterministic period of time.

If another event arrives, the same execution environment is used, and the initialization code is not run again.

If no execution environment is available, a new one is created, and initialization code is run again.

AWS Lambda functions currently provide managed runtimes for .NET Core 3.1 and .NET 6. If you want to write applications in other versions of .NET, you can use Lambda custom runtimes, or a container based version of your application.

AWS provides C# and F# project templates for Lambda functions. These can be used from the command line, Visual Studio, Visual Studio Code, and Rider.

You can run your .NET Lambda function on x86_64 and arm64 processors. The choice of processor architecture has no impact on how you write your applications. Deploying to the processor of your choice is a simple matter of changing a single configuration parameter.

You don't need to learn a new language. Use your existing C# and F# knowledge to write your Lambda functions.

You can use Lambda functions with other AWS services, such as SNS, SQS, S3, Step Functions, and DynamoDB, to create event driven applications. Or perform custom tasks in response to events from these services.

If you need to orchestrate multiple running multiple Lambda functions, you can use AWS Step Functions. With Step Functions you create a state machine that manages the execution of your Lambda functions.

There is no infrastructure to provision or manage. AWS takes care of all of this for you. All you need to decide is the processor architecture, and the amount of memory to allocate to the function. Based on your choice of memory, AWS will choose the appropriate CPU speed, network bandwidth, and disk I/O.

Your Lambda functions are highly available, and fault tolerant, running in multiple availability zones in each region.

AWS Lambda functions start within milliseconds of an event arriving, and can scale quickly, and automatically, to match the volume of incoming events.

You only pay for what you use, and this is billed to the millisecond of use.

Lambda has a generous, always free tier, allowing you to run one million free requests per month and 400,000 GB-seconds of compute time per month

If you have bursty traffic patterns, Lambda will scale to meet those needs, and when the traffic reduces, you don't pay for the resources that are no longer needed.

Lambda is part of the Compute Savings Plans, which offers lower prices in return for a commitment use a certain amount of compute time over a one to three year period.

In the next section you will see how easy it is to get started with AWS Lambda. With just a few minutes work, you will have two .NET AWS Lambda functions running in the cloud

Estimated time: 30 minutes

Please note, you may follow along with the examples presented here, but you do not need to.

If you have never worked with serverless technology, it may seem daunting at first. Even knowing how to get started can be hard to figure out.

By the end of this short module, you will have two .NET Lambda functions up and running on AWS.

One you invoke from the command line, the other via a public HTTPS endpoint that you will setup with almost no effort.

You will use the command line to create, build and deploy both examples.

This is the most basic Lambda function you can write that takes some input and returns a response, and you will have it up and running in a few minutes.

In this demo you will create a .NET API application that handles HTTPS requests. You can use the newer minimal API template, or the older full API with controllers template - the steps will be the same. If you are familiar with .NET 6 top level statements and API endpoints, consider using the minimal template - serverless.AspNetCoreMinimalAPI. If you are not familiar with top level statements, use the older template - serverless.AspNetCoreWebAPI.