It's fundamentally the same as a job queue, but the difference is that the people writing the job are not creating a running OS process. You literally just write a function, and it gets compiled into a process owned and executed by the job system.

Why would you want that? Well, who really wants to think about the OS, or how to get their data into main()? You just want to write business logic, and FaaS lets your developers focus on that. It's a small development process optimization, but a significant one at scale if you have enough developers / unique jobs being created. And it lets platform engineers focus on the best way to shovel data into main() in your particular environment.

It's a "job queue" in old-people-words, just managed by someone else. Sometimes they even offer integrations like putting a job on the queue on database triggers, or file changes.

Nothing really new, except that you don't have to build it yourself ... but if you do and you sell it to your coworkers/clients/customers, you just call it FaaS.

They recently mentioned functions as well in an article about the Threads infrastructure. https://engineering.fb.com/2023/12/19/core-infra/how-meta-bu...

No it's basically just a big background job cluster, but for all the microservices at the same time so they can get a higher average utilization out of their servers by averaging out the peaks.