Aws-lambda-dotnet: .NET 5 support?

I'm curious too about this topic, especially since waiting for next LTS (2021) sounds like a very bad (business) idea.

It is the Lambda service team's policy to support LTS versions of runtimes. We, the AWS .NET Team, are trying to work through our alternatives to see how best we can support .NET 5 with Lambda as we know there is a lot of excitement for it.

Out of curiosity from running .NET in Lambda perspective what are people most interested in with .NET 5? This helps me push priorities.

Fast startup, low footprint, and lower memory usage
static compilation of .NET (ahead-of-time – AOT)
Java interoperability - this could be a "killer feature"

Hi @andyfurniss4,

Good afternoon.

Looks like @normj had provided input on this question. Please advise if we could close this issue.

Thanks,
Ashish

Out of curiosity from running .NET in Lambda perspective what are people most interested in with .NET 5? This helps me push priorities.

I really want to move to C# 9 for Records, new Json Serialization, Nullable Type Annotations, F# 5 - in that order

I'd be curious to see how far we can get with a custom runtime instead of native .NET 5 support. Especially the link trimmer should be able to cut out a lot of unnecessary code, reducing the package size. If the custom runtime approach is not suitable, then I would be very much in favor of native .NET 5 support. As others have pointed out, the primary driver would be the new C# language features.

A custom runtime should work, but there's a bug in the .NET runtime in 5.0 RC1 that means it doesn't work in AWS Lambda (see #730). Should be good once RC2 is released.

Is using and maintaining a custom runtime much of an overhead for teams? I've not looked into it recently, last time it seemed a lot of effort, but that was for CoreRT.

E.g. setting one up, using it, updating it, etc?

What about AWS support for them?

From personal experience, the only ongoing overhead I have is bumping the NuGet package(s) and SDK once a month to pick up the latest fixes and/or security patches and then redeploying.

Otherwise I think switching to a custom runtime took me about a day to refactor and test everything and plug in the Amazon.Lambda.RuntimeSupport package.

You have to write a little bit more code and keep it up-to-date, but you can use the latest features as soon as they're available. If you don't have the bandwidth to keep things updated etc., then you can use the built-in runtime but then you have to wait for however long it takes the AWS Lambda team to make the new runtime available amongst all their other project work.

For my use cases, I feel the overhead is worth being able to update on our own schedules, rather than be tied to AWS'.

YMMV.

We are currently moving from Oracle to Aurora Postgres, as they slowed our development down as we were unable to innovate with the latest technology. Since it's Entity Framework Drivers for Oracle targeting .NET Core 3.X was just released. However, we realized we need to stay on LTS because of them. But LTS support can't come months later. Given that I think .NET 5.0 is also a good exception to the LTS plan, as it is such a monumental shift in functionality.

Any news on this now that .NET 5 is released?

My main interests are C# 9 and all the System.Text.Json updates.

Keep in mind that you can use the Custom Runtime capability to use .NET 5 today: https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas-custom-runtime/

I haven't tried it yet, but with code trimming, which is new in .NET 5, the experience should be a lot better than with .NET Core 3.0.

It is the Lambda service team's policy to support LTS versions of runtimes. We, the AWS .NET Team, are trying to work through our alternatives to see how best we can support .NET 5 with Lambda as we know there is a lot of excitement for it.

Out of curiosity from running .NET in Lambda perspective what are people most interested in with .NET 5? This helps me push priorities.

Does this mean that running lambda apps with .NET 5 will only be supported once .NET 5.0 moved from "current" to "LTS"?

.NET 5.0 will never be LTS. .NET 6.0 will be the next LTS version.

.NET 5.0 will never be LTS. .NET 6.0 will be the next LTS version.

What exactly does this mean with respect to lambdas and their support for using .NET 5.0?

It means we should not expect support for .NET 5 on Lambda since it's not going to be LTS.

It means we should not expect support for .NET 5 on Lambda since it's not going to be LTS.

Thank you @bjorg . If this is the conclusion, shouldnt this issue be closed with this as the direct answer then?

I raised this knowing that .NET 5 was not LTS and that the AWS team only supports LTS. I was wondering if an exception would be made due to the magnitude of the release and the fact that the next LTS won't be until the end of 2021. Thing is, we haven't had an explicit "yes" or "no" yet so I do not think we should close this yet. The .NET 5 release has come and gone (just like it did for 3.1) and we don't have Lambda support but that doesn't mean A) they aren't working on it or B) they aren't planning to.

If the AWS guys have decided not to support .NET 5 and they make this clear this then sure, let's close this issue. If that's the case then we'll just have to wait another 12-18 months for the next supported .NET version.

Also, I understand that there's a million other things to work on and this probably isn't trivial. I just like the shiny new things 😋

Truth is that, considering the pace Microsoft has decided to give to .NET, it doesn't make sense to wait for an LTS release every other year. Because even Current release smells like LTS when it's bound to stay around for 15 months (1 year + 3 months support).

I would be fine if AWS defined LTS and Current runtimes so that we customers could decide on which path we want to stay.

Honestly, I would be fine with a pre-cooked custom runtime for runtimes on the Current path.

Honestly, I would be fine with a pre-cooked custom runtime for runtimes on the Current path.

You say that, but others might not be as enthusiastic to get a notification from AWS in November 2021 telling them they have 3 months to update from 5.x to 6.0 before their Lambdas drop out of all support from AWS.

A lot can change in a year and suddenly a team might not have the bandwidth to react to the need to update a Lambda that might not have been touched for months to keep in support that was previously being done on their behalf by Amazon updating the hosted runtime as needed without having to think about it.

Sure, there could be a current pre-cooked current runtime with loads of warnings and caveats on it, but that would come with its own support complexities and nuances users would need to understand.

It would be great if Lambda supported all new major versions of .NET as of the day they're released by Microsoft, but I imagine the practicalities of doing that at their scale are why things are the way they are right now.

If you really, really want to be on the cutting edge and upgrade as soon as possible and support things yourself and do your own thing and be accept all the consequences, then that's kind of what custom runtimes are for.

Problem is, we are not obviously on the cutting edge. .NET Core moves fast and has been remarkably stable. Look in NuGet right now and packages are there for 5.0.0. They are for public consumption now.

While I have not tried to upgrade a DotNet Core 3.1 project to DotNet 5, so far, I have not run into any major issues in just upgrading (e.g. from 2.1 to 3.1).

DotNet 5 may be a different beast, but the custom runtimes for me are for more unusual environments like C++ Lambda.

I would rather have the updates and move to DotNet 5 Lambda sooner rather than later. 2020 has proven that a year is a loooong time :-)

I see where you're coming from @martincostello.

But this is the kind of choice that should be on customers: going Current or LTS.

AWS not releasing runtimes on Current because a customer who chose it could find itself in trouble for it is a distortion of the responsibility AWS has towards its customers. They should provide the tools and let everybody decide which tool is best suited to them.

Adding to what @genifycom said, Lambda functions are usually very simple and most of the times their code don't rely on features specific of a framework so that it makes it hard to move from one major version to another (obviously there are anomalies).

In my company we have tens of functions and most of the time we upgrade them with a folder-wide find/replace (it was a bit more complex when we had to remove the specific LambdaTools property from the project file).

I too would like to see transitive support for dotnet 5 until an LTS version is available. (this happened in the past with another version)

The only options available at the moment are:

• stay with dotnet core 3.1 and wait until dotnet 6 :(
• use a custom runtime (which in itself would be fine, however, due to lack of sufficient native AOT in dotnet 5 the startup times would likely be impacted to the extent that it would turn developers off the idea https://medium.com/@zaccharles/benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a)

Zac followed up that original post with more details about how to improve the startup performance for the custom runtime: https://medium.com/@zaccharles/net-core-3-0-aws-lambda-benchmarks-and-recommendations-8fee4dc131b0

I hope he posts a .NET 5 version, because there are a lot of compilation improvements in .NET 5 that did not exist in .NET Core 3.1, such as code trimming, which would be very useful with the custom runtime.