Serverless, FAAS and
Event-driven architectures
Serverless
Serverless offerings
Storage Services Compute
**categorized this way only for
better understanding
Serverless offerings
Storage Services Compute
**categorized this way only for
better understanding
Object Storage - AWS S3
- No upfront provisioning
- Pay per amount of data stored & accessed
- SDK/HTTP for access (multiple languages)
- Data durability guarantee (99.999999999%)
- High availability (99.99%)
- Highly scalable (multi-petabytes)
- Store any kind of files (txt, json, pdf, jpg, mp4)
- Similar offerings in GCP, Azure etc.
NoSQL Storage - Firestore
- No upfront provisioning
- Pay per amount of data stored & accessed
- SDK for access (multiple languages)
- High availability (99.999%)
- Highly scalable (millions of documents)
- Store JSON document
- Offline, Sync, Caching etc.
- Similar offerings in AWS (DynamoDB), Azure etc.
SQL - AWS Aurora
- No upfront provisioning
- Pay per amount of data stored & accessed
(Don't pay when not in use, even for RDBMS!)
- DB drivers or HTTP for access!
- Highly Resilient (6 way replication)
- Auto-Scales compute as well as storage
- Yes, RDBMS
Common theme
- No provisioning upfront
What was common in - Pay per use
- Auto scale (both up & down)
all these storage
- Resilient / Highly Available
services? - SDK for access
- Complete abstraction of servers (for developers)
Common theme
- No provisioning upfront
Key characteristics - Pay per use
- Auto scale (both up & down)
of serverless - Resilient / Highly Available
- Server management handled by provider
Serverless offerings
Storage Services Compute
API Gateway as a service
- No instance provisioning
- Auto-scale
- Pay only for requests passing through
- Feature rich - Security / Caching / Monitoring
- High availability
- Complete abstraction of servers (for developers)
Machine Learning as a service
- No provisioning of CPU/GPU/TPU
- Auto-scale
- Pay per image scanned
- Feature rich - Labels / Logo / Text etc.
- High availability
- Complete abstraction of servers (for developers)
Stream data processing as a service
- No provisioning
- Auto-scale
- Pay only for data stored & processed
- High availability
- Lightweight data stream processing
- Complete abstraction of servers (for developers)
Common theme
- No upfront provisioning
Key characteristics - Pay per use
- Auto scale (both up & down)
of serverless - Resilient / Highly Available
- Server management handled by provider
Alternate name for serverless?
"Fully managed service with no upfront
provisioning which scales up automatically,
scales down to zero, with pay per use billing
model"
** doesn't look good on marketing pamphlets :)
Serverless offerings
Storage Services Compute
Function as a service
True Serverless
AWS Lambda
Launched in 2014
AWS Compute
AWS Storage
1
code
developer
function to be executed on a request
(more granular than a microservice)
AWS Lambda
request
2
AWS Compute
AWS Storage
function
AWS Lambda
1. Auto provisioning
request
3 function AWS Compute
deployed & run AWS Storage
function
AWS Lambda
t = 300ms
request
4 request processing AWS Compute
AWS Storage
function
AWS Lambda
output
5 processing done AWS Compute
AWS Storage
function
AWS Lambda
6 destroyed AWS Compute
AWS Storage
function
Not immediately destroyed but
good to understand
AWS Lambda
1. No upfront provisioning
2. Pay per use billing
Billed for 300ms
(duration your code was running in
100ms increments) AWS Compute
AWS Storage
function
AWS Lambda
request #2
after 45 seconds
2
3 function AWS Compute
deployed & run AWS Storage
function
AWS Lambda
t = 300ms (Billed for another 300ms)
request
4 request processing AWS Compute
AWS Storage
function
AWS Lambda
1. No upfront provisioning
2. Pay per use billing
6 destroyed AWS Compute
AWS Storage
function
FAAS Scaling
1. No upfront provisioning
2. Pay per use billing
3. Highly scalable
400 simultaneous
requests 400 instances of
function running
AWS Compute
AWS Storage
**This concurrency can be
configured with max value of
1000 function
FAAS Scaling
1. No upfront provisioning
2. Pay per use billing
3. Highly scalable
active
functions/requests
function instance = 1
billing = 300ms
time
FAAS Scaling
1. No upfront provisioning
2. Pay per use billing
3. Highly scalable
active
functions/requests function instance = 5
billing = 1500ms
time
Function as a service features
Provisioning
Scaling
Billing
Events
Event driven
What is this request
request? 2
3 function AWS Compute
deployed & run AWS Storage
function
Event driven
event
3 function AWS Compute
deployed & run AWS Storage
function
Event driven
Scheduler event
- Reconciliation jobs
(run each day at 5pm) - Cache refresh jobs
2 - Reports generation
AWS Compute
3
AWS Storage
AWS's responsibility to function
trigger this event
Event driven
Resize and make copies for
multiple devices and store in
another S3 bucket
S3 event
event Output resized images
(triggered on image
upload to a bucket) stored in another bucket
AWS Compute
AWS Storage
function
Sample S3 event JSON passed to the function
Sending Slack message on every Git push
event
(http)
output
function
Push notification to user on a new follower (insert into DB)
event
output
(DB) function
IoT devices
output
event
(topic/queue) function
Event Sources
Function as a service features
Provisioning (auto)
Scaling (auto)
Billing (100ms)
Event driven
Ideal Workloads
Stateless**
Provisioning (auto) Parallel
Scaling (auto) Asynchronous**
Billing (100ms) Short-lived
Event driven Unpredictable / Bursty
Demo
Event driven architecture (flow of events)
event event
output output
bucket pub/sub topic
AWS Compute
AWS Storage
function 1 function 2
AWS Step functions
Azure has similar feature called
Durable functions
Providers
Major cloud providers
Specialized on-cloud versions
On-prem versions
Behind the scenes
container
event Container
function image
packaging
microVM
function
NodeJS
V8 Engine
packaging
Abstracted from developers
Real World Use Cases
Uses AWS Lambda to build rule-based self-managing infrastructure (create EC2 instances,
monitor infra, validate backups etc), and automate the encoding process of media files
Uses AWS Lambda with Kinesis for data ingestion pipeline for analytics service with ingestion
rate of 4,000 events per second (expected to reach 10,000 by year end).
FINRA analyzes 75 billion market events every day to identify fraud and insider trading using AWS
Lambda.
Uses AWS Lambda to process in-game screenshots (Creates thumbnails, adds watermark to the
images and shares with other players).
Uses AWS Lambda and S3 to create election county results application which runs on 1 day a
year, seeing 3,000 concurrent users. Total bill was $25.
Computing Abstractions
Compute offerings
high
FAAS
PAAS
increase in
abstraction
Containers / K8s
VMs (IAAS)
Servers
low
high decrease in complexity / low
management
Compute offerings
high
FAAS
PAAS
increase in
abstraction
Containers / K8s
Not serverless
Requires provisioning, maintenance,
VMs (IAAS)
scaling, etc. Does not scale down to 0
Servers
low
high decrease in complexity / low
management
Platform as a service
- Deploy your code (WAR file)
App Engine - Auto-scales
- Pay per hours of instance running time
- Stops when not in use
Heroku
- Fault tolerant (ensures instance remains up)
- No server maintenance by developers
- Services like Caching, Queues, Cron, etc.
- Multiple language runtimes available
- Cold starts take few seconds
**Debate whether its truly serverless
Compute offerings
high
FAAS
PAAS
increase in
abstraction
Containers / K8s
Serverless only if it can scale down to
zero, pay per use, and auto-scale
VMs (IAAS)
eg: App Engine
Servers
low
high decrease in complexity / low
management
Compute offerings
high
FAAS
PAAS Truly serverless!
increase in
abstraction
Containers / K8s
VMs (IAAS)
Servers
low
high decrease in complexity / low
management
Thank you!
FAQ
● How is the tooling support?
● Can I version the functions?
● Can I do traffic splitting, blue/green etc?
● Can I make it work multi-cloud?
Simple use case
Virtual Machines Containers / K8s - Provision the instance
(IAAS) (CAAS) - Setup / Configure / Deploy
- Patching / Resiliency / Maintenance
App Engine - 24/7 running (cost + inefficient)
FAAS
(PAAS)
No an ideal solution
Simple use case
Virtual Machines Containers / K8s - Build / Setup / Configure / Deploy
(IAAS) (CAAS) - Configure for resiliency
- 24/7 running (cost + inefficient)
App Engine - No ease of use for developers
FAAS
(PAAS)
No an ideal solution
Simple use case
Virtual Machines Containers / K8s - Deploy code
(IAAS) (CAAS) - Auto maintenance / monitoring
- 24/7 running (cost + inefficient)
Cloud Foundry
FAAS
(PAAS)
Better than previous, but can we do
better?
** App Engine is PAAS which scales down to 0
Compute offerings
Physical Servers - Provisioning
Virtual Machines (IAAS) - Server Maintenance / Patching / Resiliency
- Manual scaling (or configure)
- Pay for whole duration (even when not in use)
Containers / K8s (CAAS) - Provisioning
- Configure scaling
-
App Engine (PAAS) - Pay for at least 1 instance
Heroku - Scaling has to be configured
Cloud Foundry - No server maintenance
- Services for integration (DB, Caching, Pub/Sub, etc.)
FAAS ?
(Function as a service)
Serverless, FAAS, Event driven, Java, Micronaut, GraalVM, ZeroGC,
- What is serverless?
- UseCase #1 Cron/Batch jobs. If using Spring Boot, have to keep application up for 24/7. Wasting precious resources.
- UseCase #2 Image resizing. In addition to above, who will trigger or tell our application that image is uploaded if app is off.
- FAAS - On some event happening (image upload) we want someone (Cloud Provider) to call our function. When function's job is
over (how does it know) then stop billing...
- What types of workloads are suited to FAAS?
- Embarrassingly parallel. Bursty/Unpredictable. Event-Driven / Asynchronous. Short-lived.
- Use Cases:
-
- Data transformation
- CI/CD
- Providers
- AWS Lambda (pioneers)
- GCP, Azure etc. Fn, KNative, Cloudfare workers etc.
- Language runtimes
- Cloud providers (screenshots)
- Also option to upload Docker containers. Fargate/Cloud Run/Fn etc.
- Internals - MicroVM (firecracker), gVisor (container), Isolates (V8, cloudfare), WASM... (some will be applicable only for JS/Node
runtimes).... for developer it shouldn't matter.
- Sometimes, serverless is conflated with FAAS.
- Serverless = no provisioning capacity, scales down to 0, pay per use, auto infinite scale
-
Slides
- Pyramid of abstractions
- Characteristics - No server management, auto-scale, auto-provision, billing on per use, high availability
- Serverless - As a developer (left) you are abstracted from (cloud/serverless platform - right), provisioning, scaling & management
- Compute - BAAS, FAAS. Storage - S3, Aurora. Services - Auth0, Firebase Auth, Vision API, BigQuery etc.
- FAAS - Can also be thought as further breaking down microservices, which talk to each other using events (instead of direct calls).
- Ideal workloads - Embarrassingly parallel, stateless, asynchronous, short-lived
- Everything can produce an event, and more & more full fledged functionalities are being provided as service. Eventually its only glueing.
- This leads to event driven architecture. Many workloads are glove fit to this architecture (image, video, IoT etc.)
- How to create a function? Scheduling, http, message.
- Is PAAS serverless? No, it has to start instantly, and scale down to 0. Cloud Foundry doesn't scale down to 0 when not in use. If you are
paying even when not using (no requests are served for compute, nothing stored for storage), it's not serverless.
- BAAS - Auth0, Firebase (authentication)
- Cost - 100ms billing. Can be incredibly cheap depending on the workloads.
- But its not about cost. Economy of time and money. Its about developer freedom. Its about more focus on business value (app code)
and less on infrastructure.
- Cons -
- Cold Starts. Might not be best fit for synchronous APIs. Though, it is improving fast, and Azure allows ways around it.
- Step functions / Durable functions for complex stateful logic (can't just depend on state being in cache for a user, which actually
if you think about Cloud native, you should not anyways, you should use external cache like Redis)
- Tooling still not mature.
- Stateless? yes, but container loaded could be reused for next request. So architect for share nothing instead of stateless. Caching is
ok.
- screenshot of associating event (source) to a lambda.
- Microservices vs FAAS (PAAS vs Event-driven).
AWS Lambda
Launched in 2014
One long running application Smaller units of code each
(monolith/microservice) responding to an type of event
