Faastlane: Accelerating Function-as-a-Service Workflows
summary
Faastlane runs workflow functions as threads within a single process (on Apache OpenWhisk) so intermediate data travels by loads/stores instead of network or messaging, and it uses Intel Memory Protection Keys (MPK) to give each thread a private page key while shared pages carry outputs. Where interpreted-language GILs block parallelism, Faastlane forks processes or spawns new containers to run parallel functions. Evaluation on a 36-core Xeon shows up to 15× speedup and up to 99.95% reduction in function-interaction latency.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:16Overview of Function-as-a-Service (FaaS)
- 1:06Faas workflows: Orchestrating multiple functions
- 2:25Function interactions in a workflow instance
- 3:34Faastlane: Running functions in threads
- 4:43Challenge 1: Protect function's private memory
- 5:53Solution 1: Lightweight isolation with Intel MPK
- 8:11Challenge 2: No thread-level parallelism
- 8:55FINRA: Parallel functions in a workflow instance
- 9:27Solution 2: Dynamically switch to processes
- 10:26Solution 2: Smart scaling with containers
- 11:11Faastlane: Putting it all together
- 12:11Function interaction latency on Faas platforms
- 13:13Request throughput on Faas platforms
- 14:07Conclusion
related talks
23mFaasm: Lightweight Isolation for Efficient Stateful Serverless Computing
26mGoing Faaster: Function as a Service at Netflix
31mFaaS Meets Node.js Frameworks: Developing Cloud Native Node.js Applications at Speed
12mFaaS Platform Engineering with Wasm
39mFaaS: A Contemporary, Comparative Study
22mUnFaaSener: Latency and Cost Aware Offloading of Functions from Serverless Platforms
31mGoing FaaSter: Function as a Service at Netflix
34mFaaS and Furious - 0 to Serverless in 60 Seconds, Anywhere
