(no title)
sgtcodfish | 6 years ago
1. as a cron-style job (e.g. download a file every hour and put it in S3, or connect to a DB and do some smaller processing task) 2. as a responder to (or processor of) cloud-based events (e.g. receiving from a stream, reacting to an instance shutdown notification or an alarm) 3. as a backend for a small REST API (especially for heavily cacheable APIs)
For all 3 cases, assuming the task isn't hugely inappropriate and you've got a bit of infrastructure-as-code lying around which can be repurposed, serverless has lead to a massive time saving for me for several tasks, for very little money and with basically no maintenance effort required.
There's definitely a tendency towards smaller tasks, though. Ultimately serverless necessarily means giving up control of your infrastructure and removing a lot of customization or specialization options; that means that at a certain scale or level of complexity, it just isn't an appropriate choice either for cost or performance reasons - but that's fine, it doesn't have to solve all problems. It has its niche, and it's quite easy to go from a quick Lambda to a container-based or VM-based alternative.
yani|6 years ago
sgtcodfish|6 years ago
> assuming the task isn't hugely inappropriate
We have a couple of cases where reasonably small files (< 100MB but it'd work with larger) need to be downloaded from one place and placed in another, potentially with an ETag check to prevent redundant uploads/downloads. Lambda is perfect for that.
mcintyre1994|6 years ago
bmm6o|6 years ago
slothario|6 years ago
[deleted]