AWS Lambda Thought Experiment

[Eric Kolotyluk]

One of the problems with AWS Lambdas is that when the 'serverless' Lambda
is entered, AWS starts metering its duration.* Even if the Lambda code is
waiting for other operations, the meter is running...*

One of the nice patterns in Project Loom StructuredExecutor is
StructuredExecutor.ShutdownOnSuccess() where you can complete on the first
successful result...

So, in the AWS Lambda running with Loom, let's say we need a result, but we
know the same result is available from multiple sources, such as different
Availability Zones...

If we fork() tasks for each API source, and then cancel all the other tasks
waiting for the same result, we might reduce our metered wait time (rounded
to the nearest ms), and lower our running costs.

This could be tested in experimentation, but I wanted to see if my
reasoning is sound before investing in such an experiment.

One problem with this strategy is that there could be additional costs in
running parallel API requests?

Cheers, Eric

As an aside, I once ran an Akka Node in an AWS Lambda and was surprised to
find that when the Lambda was re-entered, the Akka Node still had its state
from before and that within the node, multi-threading worked fine. I was
going to experiment further to see if background work could still be done
outside the AWS metered duration but never got around to testing it.