[HN Gopher] AWS Lambda adds supports for .NET 6
       ___________________________________________________________________
        
       AWS Lambda adds supports for .NET 6
        
       Author : binarynate
       Score  : 82 points
       Date   : 2022-02-27 18:50 UTC (4 hours ago)
        
 (HTM) web link (aws.amazon.com)
 (TXT) w3m dump (aws.amazon.com)
        
       | jfbaro wrote:
       | Congrats to Lambda team! Keep evolving the FaaS platform,
       | especially regarding Cold Starts.
        
       | ejb999 wrote:
       | My 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.
        
       | hughrr wrote:
       | 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 :)
        
         | pharmakom wrote:
         | F# is a dream for lambdas. However, it might be worth using
         | Fable and the Node runtime.
        
         | theshrike79 wrote:
         | I your client is C#, it makes sense to share code with the
         | Lambda backend.
        
         | nwah1 wrote:
         | 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.
        
         | popotamonga wrote:
         | I do. 20M daily requests (api gateway to lambda). No issues.
         | Love it.
        
           | m0shen wrote:
           | 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.
        
         | aljarry wrote:
         | 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.
        
         | smackeyacky wrote:
         | 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.
        
         | quaffapint wrote:
         | 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.
        
         | tokamak-teapot wrote:
         | Yes. We're quite 'big' and make good use of .NET Core 3.1 in
         | Lambda
        
         | tyingq wrote:
         | It has always had much slower cold start times than other
         | choices:
         | 
         | https://mikhail.io/serverless/coldstarts/aws/
        
           | scarface74 wrote:
           | Read the comments. He did something wrong.
        
         | ftcHn wrote:
         | Yes. Good experience here.
        
         | scarface74 wrote:
         | 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 wrote:
           | I'm not pointing fingers at a team but they have far and wide
           | oversight. We're not a small customer.
        
             | scarface74 wrote:
             | I'm an employee and I'm of breaking my NDA ;)
        
       | The_rationalist wrote:
        
       | chevman wrote:
       | Shit-ton of .Net running in on-prem corporate environments still.
       | 
       | My guess is this is another carrot to get those workloads
       | migrated kids!
        
         | oatmeal_croc wrote:
         | On-prem to Lambdas? Not sure that's going to be a popular
         | migration path.
        
           | smackeyacky wrote:
           | Depends on the migration path. I would have though the
           | generic directive of "get everything out of the data center
           | and into AWS" would usually start with replicating existing
           | infrastructure, but after the bills start coming in you need
           | to deal with "why aren't we using this more effectively".
           | 
           | That's where the Lambda stuff becomes interesting. A lot of
           | systems don't need a great deal of re-designing to shift
           | workloads to serverless type processing if they are already
           | doing some kind of batch system.
        
         | sovietmudkipz wrote:
         | I agree. Even if these orgs aren't using (on-prem) FaaS
         | solutions today that doesn't mean it doesn't still sell them on
         | the cloud.
         | 
         | A car salesperson has sold the car once the customer begins
         | fantasizing about their lives inside the new car.
        
         | tyingq wrote:
         | Maybe, though Lambdas are .Net on Linux, which probably means a
         | lot of the existing workloads aren't a straightforward move.
        
       ___________________________________________________________________
       (page generated 2022-02-27 23:00 UTC)