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