This talk is a quick journey into the reasoning and beauty of serverless approach to architecture. Let's go through the platform (vendor-based, container-based, function vs service vs job) and function (functionlith/lambdalith, fat function, single purpose function, step function, routing function, circuit breaker function etc.) patterns that serverless community has come up so far with and some more. It's going to be fun!
Function vs Service
F: Fast to start, invoked on demand, uses limited resources, is not
guarateed to preserve state.
S: Always there (at least one instance), may have some long-living
internal cache, background proceses, usually takes longer to start.
D0: Custom server(s) with database software
D1: Custom container(s) with database and persistent (Kubernetes,
D2: Database server as a service (AWS RDS, MongoDB Atlas)
D3: Scalable database as a service (AWS DynamoDB, Azure Cosmos,
Dataset is small enough (upto 100MBs)
It is mostly read-only
It changes infrequently (re-deploy)
It does not affect cold start too much (upto 30 seconds)
Data is inside a function! HA database attached to public internet
traffic is expensive!
Load balancer is expensive! f1.micro with nginx was cheaper.
Indexer runs once a day with some heuristics to not over-use YouTube
What if my hardware is vulnerable? (Meltdown and Spectre)
What if my hypervisor is vulernable?
What if my operating system is vulernable? (Heartbleed)
What if my container engine is vulnerable? (CVE-2019-5736)
What if my application is vulnerable?
Risk: injection attacks
Replay attack? SQL injection? XSS? Input must be validated.
Pattern: request signing
Function expects that all incoming requests are signed (e.g. HMAC) to
check that message content didn't change in transit.
Someone called your function so many times, you have to sell your