Edit: rather than individual replies, a big thank you for everyone who replied. I am going to go and play with it now :)
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.
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.
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.
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.
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.
> > 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.
EB is not perfect, but this is totally wrong.
It can automatically:
- provision EC2 instances (using their pre-configured environments or your own Docker containers)
- set up a load balancer in front of a cluster
- scale horizontally or vertically based on load
- deploy code to all instances in a rolling fashion (zero-downtime deployments)
- run health checks to determine that instances are healthy
- automatically roll back bad deployments (also zero-downtime)
- pipe logs from all instances out to CloudWatch
- perform OS-level upgrades automatically on a certain schedule
All of this is out of the box.
You only need ssh for provisioning and when things break (like that one time etcd went crazy from a full network buffer).
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.
It suggests a few things, including:
"one of the most intensive tasks at startup is jitting your machine agnostic .NET assemblies into machine specific"
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...
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.