Show HN: Faast.js – Serverless Batch Computing Made Simple
faastjs.org
faastjs.org
Do you think serverless pricing model contradicts with batch operations ? I think that you normally pay for duration of tasks and ram usage etc. Batch jobs are supposed to be running long. I'm probably missing something here. Would you tell me little bit more ?
I especially like the cost estimate feature, that isn't something I've seen in such a seemingly simple tool like this before.
I've been wanting to make a graphql server framework that can run on lambdas, and will perhaps look into integrating with faast.
You invoke faast from your local machine (or build server, or cron job, whatever), and in turn it deploys some functions to a serverless platform and runs them, then tears them all down when complete. Eg, from the site, this code runs locally:
import { faast } from "faastjs";
import * as funcs from "./functions";
(async () => {
const m = await faast("aws", funcs);
try {
// m.functions.hello: string => Promise<string>
const result = await m.functions.hello("world");
console.log(result);
} finally {
await m.cleanup();
}
})();
It would be useful to see a discussion about how and where to host this entry code, may even a topic on "Running in production".
It's definitely a neat idea because if you control the event that kicks everything off anyway (eg: "create monthly invoices" or "build daily reports") you can deploy the latest version of everything, run it and clean it up in essentially a single step.
(Please correct me if I've misunderstood any of the details here!)
One special case is if your functions return a lot of data; outbound data charges can get expensive fast, and you'll be limited in getting responses by your network link. So you can run the coordinator code on, say, EC2 in the same region and then the link to Lambda is super fast and you won't have any outbound data costs.
https://docs.microsoft.com/en-us/azure/azure-functions/durab...
Disclaimer - product manager for Azure durable functions
There are IP-based rate limiters on sites (linkedIn, facebook, etc), but each lambda has a new public IP so by using faast.js, I can stay under the radar.
Plus you can essentially spawn a headless chrome (puppeteer) to do advanced stuff.
https://serverless.com/framework/docs/providers/
(not familiar enough with that framework to form an opinion one way or the other)
We resently were exactly in a situation where we had to do heavy processing of ~4000 items each running between 1-10minutes. To speed the process up we ran it on lambda. That means our process went down from 10h++ on a single core computer to about 15min running it on 4000 lambdas.
Your library would have saved us quite some work as it would take away a lot of Aws config, deploy, etc....
Btw: I'm thinking of building a similar library for multi core/webworkers for node.js. currently a lot of boilerplate is required on node.js to make a loop run parallel on all cores.
Faast.js can be used with multi-core, just use the "local" mode and run it on a large box. I'm billing this as a way to test locally before running in the cloud, but it's actually a completely viable way to run parallel processes on one machine, with the option to run on serverless with a one line change.
I have not deeply look into your library yet. But how do you deal with de/serialising? We use https://www.npmjs.com/package/class-transformer to correctly de/serialise ts-objects.
Also, do you create a new webworker per function call or do you create only as many workers as threads/cores on the machine and run the functions inside those? Starting a webworker can be very expensive if the serialised data is large .
Ps: each lambda function ran a special parsing of complex mathematics-excercises. We are an ed-tech company ;)
In local mode, a process is created up to the concurrency limit you specify, and each process is reused for subsequent calls (mimicking how Lambda reuses containers, allowing you to use the same caching behavior you'd use on Lambda). I'm not currently using webworkers, but that's something I could see a new mode for easily. For larger data, I would recommend storing arguments and return values directly in cloud storage like S3, or on local disk in local mode.
I would be interested to learn how your experiment with faast.js goes!
One thing I want to ask is the retries, how do you handle that currently? I ran into multiple cases where functions would fail for transient reasons.
If a function fails to execute for transient reasons and exceeds the retry maximum (a config setting you can change), then it will reject the return value promise. You can catch that and handle with another attempt, or report an error, or just ignore it and report less accurate or complete results.