10 ms·
AWS Lambda adds supports for .NET 6
- hughrr 5y agoIs anyone actually running .net in lambda? I spoke to someone internal at AWS and was told that there isn’t a lot of interest in it from customers. Edit: rather than individual replies, a big thank you for everyone who replied. I am going to go and play with it now :)
- quaffapint 5y agoWe're using it as part of an SQS flow. We add the item to the queue from our backend and then process it with a lambda function. Right now we're using containerized NET6. Works well enough.
- tyingq 5y agoIt has always had much slower cold start times than other choices: https://mikhail.io/serverless/coldstarts/aws/ https://mikhail.io/serverless/coldstarts/aws/
- scarface74 5y agoRead the comments. He did something wrong.
- ripley12 5y agoI'm curious why that is. I've spent a bit of time benchmarking startup for plain old executables, and .NET does OK there (even without AOT compilation). Not sure what would make it slower than other languages on Lambda. https://twitter.com/reillywood/status/1459332721205936128 https://twitter.com/reillywood/status/1459332721205936128
- tyingq 5y agoThere's this post: https://blog.thundra.io/solving-dotnet-lambda-cold-start-part-1 https://blog.thundra.io/solving-dotnet-lambda-cold-start-par... It suggests a few things, including: "one of the most intensive tasks at startup is jitting your machine agnostic .NET assemblies into machine specific"
- ripley12 5y agoAh, I think I see what's going on. It's trivial to precompile .NET code with ReadyToRun today, but the Thundra post was written before that was possible. And it looks like the post above forgot to enable ReadyToRun (see the comments - not sure why it wouldn't be on by default). That said, in everyday console apps on modern hardware the JIT is super quick at startup. I guess Lambdas are running in more constrained environments...
- jabart 5y agoI run some C# lambdas using the HTTP API and that post is not accurate. Our Cloudwatch numbers are way lower on less memory used. Ways for better c# production startup (AWS or on Prem) * Compile in Release mode * Test Ahead-Of-Time (AOT) mode * Limit code size. The JIT reading 200mb+ of code will be slow compared to a 15mb deployment.
- theshrike79 5y agoI your client is C#, it makes sense to share code with the Lambda backend.
- nwah1 5y agoI used it. The company was using it more like a showcase to prove that they had experience with all the hottest technology, rather than as something intrinsically advisable. I think Lambda in general is kind of a pain and likely not worth it for most of the use-cases that it is applied to. But I do think the Lambda SDK for .NET was very good. Honestly easier than working with .NET on Azure Functions.
- tokamak-teapot 5y agoYes. We're quite 'big' and make good use of .NET Core 3.1 in Lambda
- scarface74 5y agoUnless that person you spoke to is on the Lambda team breaching all sorts of NDAs telling you the metrics across all accounts, their experience is definitely anecdotal.
- hughrr 5y agoI’m not pointing fingers at a team but they have far and wide oversight. We’re not a small customer.
- scarface74 5y agoI’m an employee and I’m of breaking my NDA ;)
- pharmakom 5y agoF# is a dream for lambdas. However, it might be worth using Fable and the Node runtime.
- popotamonga 5y agoI do. 20M daily requests (api gateway to lambda). No issues. Love it.
- m0shen 5y agoIf you mind elaborating. Why? 20M req/day is =~ $2000/month in API gateway fees alone. I can imagine it depends on the performance profile, but at a previous job, I replaced a service (lots of GETs, highly cacheable) with a similar number of daily requests with 2 ec2 instances and an elb, with automatic setup / blue green etc. in a matter of hours.
- popotamonga 5y agoI know, right? Company policy. Devops team uses X so that's what we have to use. When you keep getting truckloads of cash from investors no one seems to really care much about costs.
- m0shen 5y agoAh yeah, I figured it was something like that. Seems to me that when you get into the thousands of req/sec you are still better served by simpler setups.
- runako 5y ago> I replaced a service (lots of GETs, highly cacheable) with a similar number of daily requests with 2 ec2 instances and an elb, with automatic setup / blue green etc. in a matter of hours. Most companies do not have access to an engineer capable of doing this in a matter of hours (or in infinite hours, at some firms). $2k/mo is a business-trivial amount of money to solve the problem. Ignoring the other capabilities of API gateway, that's the niche.
- smt88 5y ago> 2 ec2 instances and an elb, with automatic setup / blue green etc. in a matter of hours > > Most companies do not have access to an engineer capable of doing this in a matter of hours (or in infinite hours, at some firms). This would take ~30 min (and at no additional cost) using Elastic Beanstalk[1]. I'm sure there are better, non-free (but not expensive) EB alternatives that can target AWS resources, though. 1. https://aws.amazon.com/elasticbeanstalk/ https://aws.amazon.com/elasticbeanstalk/
- smackeyacky 5y agoI am. Using .NET Core 3.1 for quite a while to run the "batch like" jobs that get kicked off when events happen in my system (file upload in S3 -> event -> Lambda to process it). Plus a few other things, basically anything that I needed some kind of asynchronous processing to occur. The upside for me is the system is "sorta serverless" - the main website is a Docker container that has a .NET Core 3.1 web service in it. This is now setup so that a simple "dotnet ecs deploy-service" copies the container up to AWS, and triggers the load balancer setup etc. without me having to do anything. Similarly the Lambda functions are deployed with "dotnet lambda deploy-function" that just replaces the existing function. Obviously this is all more complicated than doing stuff with Python, but the ability to have a single .NET library that access all my stuff, but can be executed within the Docker container or executed as part of a Lambda function makes developing an absolute breeze. There don't seem to be any downsides to using .NET for this compared to anything else. Throw in S3 for file storage and AuroraDB as a shared database and you have something that doesn't cost a bomb to run (Aurora is the most expensive bit), is wicked fast on minimal requested hardware and bonkers reliable. The only real downside is that Lambda functions are a bit hard to do testing/debugging on but there are localised execution tools you can use to simulate AWS events that trigger Lambdas. Overall I've been surprised how good it turned out to be. I originally envisaged my system to be running on a dedicated server but this is much, much better.
- ftcHn 5y agoYes. Good experience here.
- aljarry 5y agoWe're building on .Net 5 with docker, unfortunately with cold starts it's not a good fit for client-serving APIs. Looking very much forward to drop docker and use native lambda support.
- jdmichal 5y agoI've been playing with it for running PowerShell lambda, which is maybe even more unusual than running it for just C# or F#. The only thing I don't like is that the runtime really starts choking with less than 256m of memory. It can still complete, but it will be much slower. Slow enough that it's actually cheaper in memory-seconds to just give it the extra memory.
- suzzer99 5y agoWe are. A big chunk of our app was already written in dotnet from a previous failed attempt, including the C# libraries that talk to our CRM system over SOAP. So it was a no brainer to just port the C# code to lambda. Also node is terrible at SOAP. We also have a layer of node lambdas that can be used to aggregate/transform the more granular C# lambdas, but aren't always necessary. IE - and endpoint in API Gateway can go straight to a C# lambda if the response already fits its needs.
- philliphaydon 5y agoCurently have 570 lambda's in .NET and know many people using them, feedback from AWS we've had is there's alot of people using .NET. So who really knows.
- chevman 5y agoShit-ton of .Net running in on-prem corporate environments still. My guess is this is another carrot to get those workloads migrated kids!
- tyingq 5y agoMaybe, though Lambdas are .Net on Linux, which probably means a lot of the existing workloads aren't a straightforward move.
- jayd16 5y ago.NET 6 is fairly new and after the .NET Core reunification so I wouldn't say moving to Linux is exactly the complicated part of upgrading legacy .NET apps.
- phillipcarter 5y agoIt can be. There’s a bunch of windows-specific and “this was a mistake to build” APIs that aren’t available in modern .NET. And for good reason! The big legacy .NET Framework apps all inevitably use some of them. I got a good taste of this when building the try-convert tool, and that was only focused on converting project files and package references.
- runevault 5y agoDepends on how far you're moving. Already on Core 3.1? Probably not an awful lift. If you're still trying to get off Framework if you are using certain libraries/namespaces (System.Data, WCF, System.Web, System.Addin) there is a lot more pain involved.
- smackeyacky 5y agoThe move from 3.1 core to .NET 6 was reasonably painless for me. A few of the setup classes on a web app changed but that was about it. It was much easier than .NET core 2 -> 3.1
- 5y ago
- jfbaro 5y agoCongrats to Lambda team! Keep evolving the FaaS platform, especially regarding Cold Starts.
- ejb999 5y agoMy favorite language is C#, and has been for years - also am a big user of AWS in almost all my projects - and even though I know C# much better than python or node, I still choose node or python for my lambda functions when I write them. C# I stick with to run EC2 instances, typically as windows services where it serves me well. But C# support for lambda always seem like the poor step child for AWS.
- jcims 5y agoIs it because of the deployment overhead or something else? I've inherited a pretty big C# project at work and we've just started porting it from Framework to Core. Definitely feels like there are some opportunities for serverless in there.
- DeWilde 5y agoHave you researched into .NET Core Function Apps?
- RedWarrior 5y agoWhich hurdles are you facing when transitioning from framework to core?
- to11mtm 5y ago> Is it because of the deployment overhead or something else? In my experience, two things. Smaller is the JIT overhead. Bigger, is the haphazardishness of the other AWS Libraries for .NET; there's sometimes 'edge cases' where if running in a lambda, you have to do something special, set a special flag, etc. And often the solution is buried in a SO post or closed github issue.
- PetahNZ 5y agoHow about php then, a language that seems so suited to the lambda runtime model, but then only supported through custom docker runners.
- CSSer 5y ago
- The_rationalist 5y ago
- unfunco 5y agoSurely .NET usage on AWS lambda is nowhere close to Node.js, and the Node.js 16 LTS has been out for almost a year and there's still no support for it.
- otterley 5y agoAmazonian here! (Speaking for myself, not for the company.) You can use any runtime you like for your Lambda functions, even if it's not supported as a first-class native runtime. The simplest way is to build a container image that has the runtime you want to use. All you need to do is to include the Lambda Runtime Interface Client with your image, and set the proper ENTRYPOINT. See https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-containe... for a blog post, and https://docs.aws.amazon.com/lambda/latest/dg/images-create.html https://docs.aws.amazon.com/lambda/latest/dg/images-create.h... for the reference documentation. Once you get the hang of it, it's super easy, and you may never want to go back to the old way!
- phillipcarter 5y agoJust speculation, but there may be different teams (or subsets of teams) responsible for different kinds of bindings, and it may be easier to support the latest .NET LTS than the latest Node LTS.
- briHass 5y agoIt'll be interesting to see how this performs vs. the offering in Azure: Azure Functions. AF was very, very slow (especially cold) early on, but it seems much better now. Still not ideal, however, and I wonder if Lambda will be faster.
- arjvik 5y agoNow that you can run containers on Lambda, why are individual releases like this still important? Couldn't you just deploy your own runtime in Docker?
- nhoughto 5y agoYou can package a lambda as a container image, but lambda doesn’t itself run the container like it would in dockerd or kube etc, it’s just a packaging mechanism I believe.
- Dunedan 5y agoUsing Docker images as deployment packages for AWS Lambda has two notable disadvantages from my point of view: - You're suddenly responsible for managing the whole operating system again, neglecting one of the major benefits of AWS Lambda. - You need to store the Docker images in AWS Elastic Container Registry (ECR) which adds additional complexity to the setup.
- deleted 5y ago[deleted]