5 ms·

Is 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: rathe

by hughrr 5y ago

Is 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 ago
We'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 ago
It 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 ago
  Read the comments. He did something wrong.
- ripley12 5y ago
  I'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 ago
    There'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 ago
      Ah, 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 ago
  I 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 ago
I your client is C#, it makes sense to share code with the Lambda backend.
nwah1 5y ago
I 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 ago
Yes. We're quite 'big' and make good use of .NET Core 3.1 in Lambda
scarface74 5y ago
Unless 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 ago
  I’m not pointing fingers at a team but they have far and wide oversight. We’re not a small customer.
  - scarface74 5y ago
    I’m an employee and I’m of breaking my NDA ;)
pharmakom 5y ago
F# is a dream for lambdas. However, it might be worth using Fable and the Node runtime.
popotamonga 5y ago
I do. 20M daily requests (api gateway to lambda). No issues. Love it.
- m0shen 5y ago
  If 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 ago
    I 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 ago
      Ah 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 ago
I 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 ago
Yes. Good experience here.
aljarry 5y ago
We'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 ago
I'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 ago
We 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 ago
Curently 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.

by hughrr 5y ago

quaffapint 5y ago

We'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 ago

It 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 ago
Read the comments. He did something wrong.
ripley12 5y ago
I'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 ago
  There'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 ago
    Ah, 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 ago
I 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 ago

I your client is C#, it makes sense to share code with the Lambda backend.

nwah1 5y ago

I 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 ago

Yes. We're quite 'big' and make good use of .NET Core 3.1 in Lambda

scarface74 5y ago

Unless 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 ago
I’m not pointing fingers at a team but they have far and wide oversight. We’re not a small customer.
- scarface74 5y ago
  I’m an employee and I’m of breaking my NDA ;)

pharmakom 5y ago

F# is a dream for lambdas. However, it might be worth using Fable and the Node runtime.

popotamonga 5y ago

I do. 20M daily requests (api gateway to lambda). No issues. Love it.

m0shen 5y ago
If 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 ago
  I 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 ago
    Ah 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 ago

I 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 ago

Yes. Good experience here.

aljarry 5y ago

We'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 ago

I'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 ago

We 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 ago

Curently 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.