This is a presentation for JavaScript Meetup Luxembourg JUNE 2018 on our experience with running APIs on Serverless Architecture (AWS Lambda). Presenting also the Serverless framework quickly
fully managed environment, where you are billed by execution time. The deployed code is invoked by a trigger History • 2006 - Zimki • 2008 - Google App Engine • 2014 - AWS Lambda • … Google Cloud Functions, IBM OpenWhisk, Azure Functions,.... 6
Architectures/Languages, you have to use one of them, Code Package Size is limted, and RAM for execution is also limited • NodeJs, Python, Java Choose carefully as great impact on “performance” (cf. later) WARNING 7
have to distinguish between the following cases 1. Many Triggers and requiring Low latency (Faas As API) 2. Bursts of High Computational Tasks (Background jobs) 3. Few Triggers (Hosting personal website ) 4. ... Scenario 2 and 3 are optimal use cases for FaaS Architecture, 1 needs improvement from providers My Humble Opinion 9
https://github.com/littleiffel/jsmeetup-serverless-most-simple-example • API with ExpressJs - https://github.com/littleiffel/jsmeetup-serverless-api-demo-express 18
separation of concerns • Using ExpressJS -> Create one “Function”(App) to handle all calls ◦ Creates a little overhead to re-transform event to HTTP Request 19
is spawned, when function is busy • Every new spawned function is cold-started • Heavily varying traffic Pattern (high/low) • => Many cold starts === Bad Performance === Slow response times Providers need to allow to set and control Concurrency level, or permit delay before deploying new function My Humble Opinion 24
• Adding Lambda to a VPC adds 10 seconds to cold start • 10 Seconds...Yes...10 Seconds • At least • Avoid to put it into a VPC • At all costs!! (if you want to stay under 10 seconds response time) 26
Up to a certain limit (max 60 minutes) • Require special function parameter or other way to trigger function without adding much load • Define a cron that triggers functions regularly ◦ You need to keep ALL parallel instances of your functions warm to avoid cold starts 29
and .Net seems most stable and fastest ◦ but... • Package Size • Memory Settings ◦ The more the better • Cold Starts ◦ Bad for compiled languages (Java,..) • Data Storage • Parallelism • Keep them Hot • VPC (AWS specific) ◦ STAY AWAY FROM VPC!!! 32
Resource-limitations (No Problem) • Performance CHECK, this is a problem ◦ Cold Starts for API are a BIG problem • Monitoring & Debugging (No Problem) • No Control on ApiGateway and Parallelism ◦ WISH: Control how long requests are queue before cold-starting a new function • Vendor Lock (Optional :)) ◦ Frameworks could eventually separate Platform from Application code 34
Good ◦ Deploy without downtime Great • Scalability Problematic ◦ Does your Data Store scale? ◦ Cold-Starts problems increase with scale • Performance All Good • Productivity All Good • Integration NO VPC!!! 35
Define Timeout for waiting before spawning new function • Control Level of Concurrency (ReservedConcurrentExecutions on AWS) • Be able to define a Lifetime of functions • Scale Data Store with Number of deployed functions 36