A Cloud Guru Blog

How about this: https://read.acloud.guru/serverless-superheroes-eric-hammond-aws-lambda-and-the-power-of-code-31f847a2150f

From the article:

> The most surprising thing I learned from building TimerCheck.io was: If designed well, it is possible for some products built with services like AWS Lambda, API Gateway, and DynamoDB (often categorized as “serverless”) to require zero technical maintenance! The public, free TimerCheck.io microservice API was released in July 2015 and I have never had to do anything to keep it working or to scale it, with one notable and unexpected exception.

> The only time I had to do work on TimerCheck.io was when Amazon declared that AWS Lambda support for Node 0.10 was being phased out. If my code base had been larger, it probably would have been easier to simply upgrade to Node 6.10, but I decided instead to rewrite the function in Python 3.6. It has continued operating smoothly since.

> As part of the rewrite, I also took advantage of one of several good AWS Lambda deployment tools that have arisen to fill what was an important gap when Lambda was launched. I chose Amazon’s open source chalice tool for this project, and was thrilled with how it eliminated all the work of setting up an API Gateway, a formerly daunting task.

> The TimerCheck.io service has had a few short outages over the years, but they were always due to region-wide problems that AWS experienced, and AWS resolved the issue without me having to lift a finger. Even with a lot…

From the research I did, here's how languages stack up in Lambda runtime (lowest first):

1. Python & JS
2. Go
3. C# & Java

I couldn't find any data on Rust.

The understanding at the time was that Python & JS runtimes are built-in, so the interpreter is "already running" Go is the fastest of compiled languages, but just can't beat the built-in runtimes. C# and Java were poorest as they're spinning up a larger runtime that's more optimized for long-running throughput.

https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html

https://medium.com/the-theam-journey/benchmarking-aws-lambda-runtimes-in-2019-part-i-b1ee459a293d

https://epsagon.com/development/aws-lambda-programming-language-comparison/

https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-java-c-and-go-29c1163c2581

Of course, benchmarks like this only go so far. Use as a starting point for your own evaluation; not as an end-all-be-all.

If I understand your suggestion right, it's to heartbeat concurrently to force more warm instances. We have played with that, but spikes are spikes - the most interesting ones defy expectations. As with many apps, the conditions that make us spike make performance more important, not less.

Just found the same author as OP with a clever solution here: https://read.acloud.guru/cold-starting-lambdas-2c663055589e

Having the app pre warm instances on a per-user basis is super cool -- for user-driven workloads like web servers. To make matters worse, we are serving an API that takes hits from third party streams -- so our concurrency is based on their client behavior, not something we can easily link to a session scope, like users. Tricky!

F# actually rusn _very_ well on AWS. There is some official scaffolding tooling you can use[0], and performance with .NET Core is more than sufficient for what your business likely needs[1]. Love this quote: "Both C# and F# on .Net Core 2.0 exceeds all expectations and outperforms all other runtimes in average duration".

Thanks for the compliment! And I hope that it all goes well with you.

[0]: https://aws.amazon.com/blogs/developer/f-tooling-support-for-aws-lambda/

[1]: https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-java-c-and-go-29c1163c2581