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.
Is 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.
> 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.
As much as I love Node and Node on Lambda, AWS's unwillingness to stick to any kind of a predictable timetable, or at least communicate, for new LTS stable versions of Node has me bemoaning the platform every time a new even-numbered release comes out.
Yea as others have said, it's a shared nothing request model, but also single threaded, with built in memory and time limits, basically exactly how lambda runs (you can of course share memory, and multithread if you want to but its pretty uncommon practice in php).
I don't really see it as a "limitation" as it really makes grokking the code much easier than other languages. Probably >95% of libraries out there make this assumption as well, so its not just "how it is used" but also the culture and existing code that make this assumption.
What’s old is new again. It’s like, hey, let’s go back to the CGI model and reinvent it. Never mind there are still languages using it! Forget them! /s
But C# support for lambda always seem like the poor step child for AWS.