1. DEFINIZIONI - Perché  Serverless / Cos’è Serverless - Le promesse di serverless - Use case 2. I PRODOTTI DISPONIBILI - Confrontare prodotti serverless - Il mercato FaaS - La famiglia AWS serverless 4. STRUMENTI E BEST PRACTICE - Strumenti AWS - Framework e ambienti di sviluppo - Testing - Debug, log, monitoraggio 3. DESIGN E ARCHITETTURA - Performance e Capacity - Deploy e Release - Gestione costi

1. APPLICAZIONI
SERVERLESS CON AWS
Progettare e sviluppare soluzioni
basate sulle tecnologie serverless
03/2022

2. IMAGE GOES OVER HERE
Marcello Testi
● Solution Architect (cert. AWS), Scrum Master (cert. SA)
● Agile mindset, Cloud Native tech
● https://www.linkedin.com/in/mtesti/?locale=it_IT
● https://www.sparkfabrik.com/

3. Mattino
● Panoramica su soluzioni disponibili
● Considerazioni sul design
● Demo su concetti e soluzioni
presentati
Pomeriggio
● Hands-on!
● Implementazione pratica di un piccolo
progetto
● Lavoro a gruppi

4. Non sarà possibile parlare in modo approfondito
di ogni servizio AWS citato
AWS
disclaimer!

5. Di cosa parleremo…
1. DEFINIZIONI
Perché Serverless / Cos’è Serverless
Le promesse di serverless
Use case
2. I PRODOTTI DISPONIBILI
Confrontare prodotti serverless
Il mercato FaaS
La famiglia AWS serverless
4. STRUMENTI E BEST PRACTICE
Strumenti AWS
Framework e ambienti di sviluppo
Testing
Debug, log, monitoraggio
3. DESIGN E ARCHITETTURA
Performance e Capacity
Deploy e Release
Gestione costi

6. 1. DEFINIZIONI

7. Serverless:
origini
● 2008: Google App Engine
● 2010: PiCloud
Focus su applicazioni, primi FaaS con molti
limiti: supporto solo per Python, timeout,
storage
● 2014-2015: Lambda
● 2016-: Google Cloud Functions, IBM, Microsoft
Azure, Cloudflare, Oracle, Alibaba…
Focus su architettura event-driven, supporto
per più linguaggi
… e poi serverless Data Storage, Containers, API
Management, Messaging…

8. Serverless:
evoluzione
Direzioni evoluzione servizi serverless (FaaS):
● Supporto per più runtime + custom runtime
● Supporto per più fonti di eventi
● Maggiore flessibilità nella scelta di risorse di
computing e storage
● @Edge

9. Serverless
● Competenza del cloud provider: gestire i
server e l'allocazione di risorse in modo
dinamico
● Costi basati su consumo effettivo di risorse
● Scaling, capacity planning e manutenzione
possono essere resi trasparenti rispetto a
sviluppatori e operatori
● Applicazioni serverless possono essere
costituite anche da elementi server-based, o
rappresentare architetture interamente
serverless
Wikipedia

10. Serverless
● Servizi di backend tariffati in base all'utilizzo
● Per effettuare deployment non serve
occuparsi di infrastruttura
● Applicazioni event-driven ed eseguite in
edge-computing»
Cloudflare

11. Serverless
● Creare ed eseguire applicazioni senza dover
gestire i server
● Il codice viene rilasciato in container
● Il modello di esecuzione è event-driven
● Esecuzioni, scaling e billing basati sulla
precisa richiesta di servizio
● Risolve il problema di chi deve gestire
capacity imprevedibili o altamente variabili
CNCF

12. Serverless
● Tecnologia per eseguire codice, gestire dati,
integrare servizi, senza dover gestire server
● No attività di gestione dell'infrastruttura da
parte dell’utente
● Scaling automatico
● High Availability (replica automatica su AZ
multiple) inclusa
● Costo per uso effettivo
AWS

13. Perché
Serverless?
● Migliorare prestazioni e affidabilità (cfr. SRE)
● Migliorare la sicurezza, circoscrivendo il
perimetro della soluzione da proteggere: solo
business logic, all’infrastruttura pensa AWS
● Tenere sotto controllo i costi evitando
overprovisioning
● Aumentare l’agilità, la capacità di rispondere al
cambiamento e alla richiesta di innovazione
● Migliorare l’esperienza degli sviluppatori
riducendo la complessità che devono gestire,
standardizzando gli strumenti

14. Le promesse di serverless
1. DEFINIZIONE

15. Promesse da
serverless…
● Nessuna gestione dei server
● Scaling automatico in base all’uso
● Nessun addebito per il tempo di non
utilizzo
● High Availability e tolleranza degli
errori incluse

16. Promesse da
serverless…
Minori costi fissi: si paga per valore e
servizi effettivamente utilizzati
AWS

17. Promesse da
serverless…
Focus sullo sviluppo del prodotto e sulle
sue caratteristiche uniche, possibilità di
non preoccuparsi dell’integrazione con i
servizi, che è inclusa e non richiede
faticose configurazioni
AWS

18. Promesse da
serverless…
Nessun bisogno di gestire server: il ciclo
di release e deployment è più rapido e
meno complesso, aumentando
(potenzialmente) la frequenza di rilasci e
il time-to-market
AWS

19. Serverless non
può
promettere…
Gestione dello stato (memory e storage)
attraverso diverse invocazioni della
stessa funzione

20. Serverless non
può
promettere…
Tempi di risposta garantiti (cold start
può non essere breve)

21. Serverless non
può
promettere…
#NoOps: i sistemi non richiedono
amministrazione, ma le applicazioni
richiedono monitoraggio, debug,
pipeline di QA e dei deployment…
Questo però può essere semplificato con
strumenti IaC per configurare i servizi
cloud

22. Serverless non
può
promettere…
Implementazioni indipendenti dai vendor

23. Use case
1. DEFINIZIONE

24. Trasformazione
Cloud Native
Prima di elencare use case “tecnici”, qualche
considerazione strategica
● Serverless può essere considerato un approdo
o una tappa nella migrazione delle applicazioni
a un approccio Cloud Native
● FaaS per esempio implementa o abilita alcuni
dei principi di 12-factor app (codebase,
dependencies, build-release-run, processes,
concurrency)
The twelve-factor app

25. Trasformazione
Cloud Native
Possibili percorsi di modernizzazione di un’app
● Da architettura basata su VM/EC2 a
Serverless, passando per una fase intermedia
che usa i container
● Da architettura basata su container a
Serverless (eventualmente usando container
runtime in Lambda)
● Serverless-first, creando direttamente come
FaaS i nuovi servizi e migrando
progressivamente gli altri
Lego Case Study (re:Invent 2020)

26. Trasformazione
Cloud Native
Serverless è inoltre compatibile e abililtante per
l’approccio DevOps, grazie all’automazione,
fornisce agli sviluppatori strumenti per gestire
rapidamente cambiamento e innovazione
● Provisioning infrastruttura: da CloudWatch,
si può implementare un approccio
event-based, grazie a IaC (CloudFormation)
● Soprattutto è possibile creare un workflow
CI/CD di sviluppo e rilasci (QA inclusa)
● È un’ottima base per costruire una Developer
Platform

27. Utilizzo incostante

28. Architettura event-driven

29. Architettura microservices con frontend
HTTP-based

30. Integrazione IoT

31. Chatbot e interfaccia vocale

32. Data e media processing
Specialmente in modalità asincrona

33. 2. I PRODOTTI DISPONIBILI

34. Fattori nel
confronto di
prodotti
serverless
● Integrazione con altri servizi
(ecosistema vendor)
● Facilità d’uso / Developer UX
● Prestazioni: disponibilità “@Edge” e
possibilità di configurare servizio
secondo usi previsti

35. ● Pricing e billing
○ http://serverlesscalc.com/
○ Da considerare anche eventuale
presenza di free tier
Fattori nel
confronto di
prodotti
serverless

36. Fattori nel
confronto di
prodotti
serverless
(FaaS)
● Supporto per linguaggi
● Limiti
○ Concurrency
○ Memoria
○ Durata esecuzione
○ Dimensioni payload

37. Vendor lock-in
● Disponibilità dei linguaggi (oggi
problema abbastanza circoscritto)
● Formati proprietari di eventi - legati a
integrazione con ecosistema vendor
● Sistemi proprietari di packaging e
deploy per le funzioni

38. Vendor lock-in
Soluzioni? Progetti open - CNCF
● CloudEvents: standard per descrivere
i dati degli eventi
● Vari prodotti da eseguire on-premises
e in-cloud (es. Knative)
CNCF Serverless Landscape

39. Confronto tra vendor FaaS
AWS Lambda
Azure Functions
Google Cloud Functions
IBM Cloud Functions
Oracle Cloud Functions
Cloudflare Workers
Alibaba Cloud Function Compute
Netlify Functions

40. Famiglia dei prodotti serverless AWS
2. I PRODOTTI DISPONIBILI

41. Prodotti serverless AWS
Computing
● Lambda
● Lambda@Edge
● Fargate (serverless cluster)
● Step Functions (orchestrazione di funzioni)

42. Prodotti serverless AWS
Storage
● S3
Data Store
● DynamoDB (NoSQL)
● Aurora Serverless (RDB)
● RDS Proxy
API
● API Gateway
● AppSync (GraphQL)

43. Prodotti serverless AWS
Stream di dati e messaggi
● SNS
● SQS
● Kinesis
● EventBridge
Analytics
● Athena (serverless SQL su dati provenienti da S3)

44. Prodotti serverless AWS
Container
● Lambda (container runtime)
● Fargate (serverless cluster provisioning)
● Elastic Container Registry
● App Runner

45. Lambda
2. I PRODOTTI DISPONIBILI

46. Lambda
● Lambda è l’implementazione FaaS di
AWS
● Esegue on-demand e scala a zero
● Perno di ecosistema serverless AWS,
ma non tutte le implementazioni
serverless passano da Lambda (es.
RDB Aurora Serverless, Fargate per i
container)

47. Lambda:
sicurezza e
permessi
● IAM per gestire l’accesso a funzioni e
altre risorse (versioni, alias, config) da
parte di utenti o altri servizi AWS
● Execution role: assegnato a funzione
per interagire con altri servizi
○ Di base contiene accesso a
CloudWatch
○ Serve anche per accedere ai servizi
che funzionano da trigger (es. S3)

48. Lambda:
componenti in
AWS Console
● Lambda (codice, layer)
● Trigger (origini eventi)
● Destinazioni (possono essere diverse,
anche in base a successo esecuzione)
● Versioni e Alias
● Configurazione (specifica per
elemento selezionato: Lambda,
trigger o destinazione)

49. Anatomia di
una funzione
Lambda
● Handler: la funzione che viene
eseguita
● Event Object: dati (JSON) dell’evento
che ha invocato la funzione
● Runtime: ambiente in cui viene
eseguita la funzione (es. NodeJS)
● Context: metodi e proprietà disponibili
in base a runtime

50. Lambda:
configurazione
base
● Scelta runtime
● Indicazione handler
● Assegnazione memoria
● Timeout esecuzione

51. Lambda: altre
configurazioni
● Concurrency
● Comportamento async
○ Numero retry
○ Età max evento
○ Queue per eventi falliti (SQS)
● Monitoraggio (CloudWatch, X-Ray,
Lambda Insight)

52. Lambda: altre
configurazioni
● Tag
● Variabili d’ambiente
● Collegamenti a risorse altri servizi
○ File System (EFS)
○ VPC
○ DB Proxy (interazione con RDS)

53. DynamoDB
2. I PRODOTTI DISPONIBILI

54. DynamoDB
● NoSQL
● Focus su performance e scalabilità
● Caratteristiche
○ Capacity configurabile o on-demand
○ High Availability
○ Backup on-demand e point-in-time
recovery
○ TTL e eliminazione automatica item
“scaduti”

55. DynamoDB:
concetti base
● Table, Item, Attribute
● Primary key (partition o partition+sort)
● Schemaless
● Read consistency (eventual vs strong)
● Query vs Scan

56. API Gateway
2. I PRODOTTI DISPONIBILI

57. API Gateway
● Servizio managed per creare API HTTP
(RESTful), REST, Websocket
● Permette di delegare:
○ Routing
○ Autenticazione
○ CORS
○ Versioning

58. Utenti di API
Gateway
● Sviluppatori di API/Funzioni
○ Configurano API per fornire le
funzionalità richieste
○ Configurano l’accesso
● Sviluppatori di app che consumano
API per accedere a dati e funzionalità

59. Integrare API
REST con
Lambda
● Lambda proxy integration
○ Richieste inviate direttamente a
Lambda, che provvede a eventuali
trasformazioni e a fornire risposta
● Lambda non-proxy integration
○ Richieste processate da API
Gateway, che provvede anche a
fornire risposta

60. Aggiornamenti e tendenze
2. I PRODOTTI DISPONIBILI

61. Aggiornamenti
Lambda
● Disponibilità hardware Graviton2
come opzione (adatto a uso intenso
risorse, in certi scenari più
efficiente/cost-effective)
● Accesso cross-account a immagini
container su ECR
● Migliore capacità di filtrare eventi, per
evitare invocazioni inutili e rimuovere
codice non applicativo da funzioni

62. Aggiornamenti
API Gateway
● Supporto per certificati di terze parti,
non forniti da ACM
● Integrazione con Step Functions, che
ora possono invocare un endpoint:
combinazione di SF e AG permette di
avere in servizi managed gestione
errori, autenticazione e controllo sul
carico di richieste

63. Aggiornamenti
Step Functions
● Tool visuale “Workflow Studio” per
disegnare e implementare il flusso di
esecuzione
● Supporto AWS SDK per migliore
integrazione con altri servizi, senza
dover aggiungere codice alle funzioni
● Supporto per AWS Batch
● Capacità di inviare eventi su bus di
EventBridge

64. BREAK & QA

65. 3. DESIGN E ARCHITETTURA

66. Performance e capacity
3. DESIGN E ARCHITETTURA

67. Concurrency
limits
● Concurrency : FaaS = Horizontal
Scaling : EC2
● Quante istanze della funzione possono
essere eseguite allo stesso tempo

68. Cold start
● Problema visibile soprattutto in caso
di scaling (rischia di allungare tempi e
ridurre efficacia)
● Soluzioni primitive prevedevano di
“pingare” periodicamente una funzione
per tenerla “calda”
● AWS offre soluzione (per $)

69. Cold start
● Fattori che influenzano cold start
○ Linguaggio (ling. compilati
richiedono ambienti più complessi e
più tempo)
○ Dimensioni pacchetto
○ Risorse assegnate (+ risorse, -
tempo)
○ Numero di dipendenze
Ricerca

70. AWS:
concurrency
● Limite regionale per tutte le funzioni
● Reserved concurrency
○ Riserva slot di esecuzione non
utilizzabili da funzioni unreseved
○ Imposta un limite alla concurrency
della funzione

71. AWS:
concurrency
● Provisioned concurrency
○ Mitiga il problema del cold-start,
esegue codice di inizializzazione
prima dell’invocazione delle funz.
● Application autoscaling
○ Automatizza la quantità di
provisioned concurrency in base al
carico

72. AWS: limiti di
configurazione
Lambda
● Esecuzioni contemporanee: base
1000
● Storage: base 75GB (512MB per /tmp)
● Memoria: 128 > 10240 (1MB incr.)
● Timeout: max 15 minuti
● Payload: 6MB sync / 256KB async

73. AWS: limiti di
configurazione
Lambda
● Dimensioni pacchetto
○ Zip: 50MB (250MB dopo unzip)
○ Da console: 3MB

74. Deployment e release
3. DESIGN E ARCHITETTURA

75. AWS Lambda:
deployment
● Gestione manuale per singole funzioni
con versioni e alias
● Gestione stack (CloudFormation)
come “Applications”
○ Da console
○ Con SAM CLI
○ Con altri framework (es. Serverless
Framework)

76. AWS Lambda:
deployment
● Con le versioni è possibile taggare un
determinato stato della funzione
(codice, runtime, impostazioni)
● A ogni versione è assegnato un ARN
specifico, referenziato per esempio da
un API Gateway endpoint

77. AWS Lambda:
deployment
● Con gli alias è possibile referenziare
una versione per mantenere stabile il
riferimento a ARN
● Nel definire un alias si possono
referenziare 2 versioni e quindi
realizzare un deployment graduale
(“traffic shifting”)

78. AWS Lambda:
application
deployment
● Tramite la console e (via CLI) con SAM
o altri framework è possibile gestire il
deployment di interi stack (funzioni,
trigger/origini di eventi, API endpoint)
basati su CloudFormation
● In questo caso si può usare il
versioning di Lambda ma di solito è
preferibile una gestione del codice
con git o equivalente

79. AWS Lambda:
best practice
per
deployment
● Usare i layer (max 5 per funzione) per il
codice condiviso tra funzioni (es.
logging)
● Usare integrazione di CodeDeploy
(anche in SAM)
○ Versionamento funzioni
○ Traffic shifting: spostamento
graduale del traffico su nuove
versioni

80. AWS Lambda:
best practice
per
deployment
● Traffic shifting
○ Canary: 2 fasi. Config intervallo tra
fasi e % traffico spostato nella
prima fase
○ Linear: spostamento a intervalli
regolari. Config durata e % traffico
spostato per ogni intervallo
● Allarmi CloudWatch possono essere
usati per controllare deployment ed
eventualmente fare rollback

81. Gestione dei costi
3. DESIGN E ARCHITETTURA

82. Pricing
Lambda
● Numero di richieste
● Durata*memoria utilizzata
● Traffico in/out (stessi prezzi EC2)
○ Traffico gratuito verso servizi AWS
dell’ecosistema serverless: S3, SQS,
DynamoDB, SNS e altri
● Costi per richieste e durata superiori
per provisioned concurrency

83. Pricing
DynamoDB
● On-demand (RRU/WRU) / Provisioned
(RCU/WCU)
● Storage
● Backup
● Extra per Global Tables e DAX
● Traffico out gratis verso altri servizi
AWS in stessa regione

84. Pricing API
Gateway
● Numero di richieste
● Tipo di API (HTTP/REST)
● Traffico in/out (stessi prezzi EC2)

85. Pricing
Lambda
best practice
● Non aumentare oltre il necessario il
timeout per le funzioni
● Ottimizzare al massimo l’uso della
memoria
● Usare CloudWatch per controllare
concurrency, errori/retry e utilizzo
memoria
● Usare AWS Budget

86. Pricing
Lambda
architettura
● Un’architettura basata su richieste
sincrone può anche scalare
indefinitamente, ma rischia di costare,
oppure di generare errori se si
imposta concurrency bassa
● Architettura event-driven basata su
richieste async permette di tenere
sotto controllo costi legati allo scaling,
senza sacrificare affidabilità

87. Pricing
serverless
costi da
controllare
● Servizi esterni che possono rallentare
esecuzione
● Cold start
● Retry in caso di errori
● Richieste e traffico API Gateway
● Traffico Lambda verso servizi non
serverless o verso internet
Approfondimento

88. 4. STRUMENTI E BEST PRACTICE

89. Strumenti AWS per lo sviluppo serverless
4. STRUMENTI E BEST PRACTICE

90. Applicazioni
Lambda in
Lambda
Console
● Applicazioni: combinazioni di funzioni
Lambda, origini di eventi e altre
risorse usate per eseguire task
● Lambda Console permette di gestire
le applicazioni
● Elenca gli stack CloudFormation che
contengono risorse Lambda

91. Applicazioni
Lambda in
Lambda
Console
● La sezione di monitoraggio di
un’applicazione aggrega le metriche
per tutte le risorse osservabili dello
stack

92. Applicazioni
Lambda in
Lambda
Console
● Creare un’applicazione configura
anche i servizi consigliati per gestirne
il ciclo di vita
○ Permessi e Ruoli
○ CodeCommit (git)
○ CloudFormation
○ CodePipeline
○ CodeBuild

93. Serverless
Application
Model
● Estensione di CloudFormation
● Template YAML che definiscono
risorse e configurazione
● Parametri per gestire input e creare
stack dinamici da stesso template

94. Serverless
Application
Model

95. Serverless
Application
Model
● Fornisce sintassi per definire
○ Funzioni (runtime, codice, handler)
○ API endpoint
○ Tabelle DB (DynamoDB)
○ Mapping di origini eventi
○ Policy di accesso / permessi
● In quanto estensione di
CloudFormation, è possibile definire
anche risorse non-serverless

96. Serverless
Application
Model
● Essendo template, è possibile
effettuare il deployment con
caratteristiche identiche su ambienti
multipli (es. dev, test, prod)

97. SAM CLI
● Interfaccia da terminale per
○ Build
○ Test
○ Debug
○ Deployment
● Permette anche di eseguire e testare
in locale le funzioni

98. CDK
Cloud Development Kit
● Permette di definire e creare risorse
cloud utilizzando linguaggi di
programmazione diffusi (es. Java,
Python)
● Permette quindi anche di definire
Lambda usando lo stesso linguaggio
del codice da eseguire, es. Python

99. Serverless
Application
Repository
● Archivio di applicazioni riutilizzabili
● Possono essere condivise
pubblicamente o con specifici
account AWS
● Pacchetti basati su template SAM +
link a codice funzioni (per applicazioni
pubbliche)

100. Framework e ambienti di sviluppo
4. STRUMENTI E BEST PRACTICE

101. Ambiente di
sviluppo
serverless
● Architettura applicazioni serverless è
basata su integrazione tra servizi AWS
● Costruire un ambiente locale di
sviluppo non è banale
● Framework, IDE aiutano a questo
scopo

102. Framework
● Serverless Application Model (SAM)
● Serverless Framework
● Spring Cloud Function

103. Serverless
framework
● CLI + hosted dashboard
● Rispetto a SAM, aggiunge monitor,
alert, strumenti di supporto ai test
Link

104. Serverless
framework vs
SAM
● SAM è più opinionato (si intuisce
vedendo la struttura del progetto base
creato)
● Efficacia della rimozione delle risorse
dello stack è migliore in SF (SAM non
rimuove automaticamente S3)

105. Serverless
framework vs
SAM
● Il supporto community è migliore per
SF (più attività su Github/StackOF, più
disponibilità di esempi e tutorial,
ecosistema plugin)
● SF supporta multi-cloud
● SAM include strumenti per testing

106. IDE
● AWS CLoud9
● Plugin per Eclipse (Java) e Visual
Studio (.NET)
● Visual Studio Code AWS Toolkit

107. Testing
4. STRUMENTI E BEST PRACTICE

108. Testing best
practice
● Scrivere funzioni secondo design
pattern che le rendano facilmente
oggetto di unit test
● Focus su unit test e test di
integrazione
● Non eseguire test di integrazione su
simulazioni locali dei servizi
● Eseguire test end-to-end in cloud,
possibilmente in ambiente creato per
ogni singola esecuzione test

109. Debug, log, monitoraggio
4. STRUMENTI E BEST PRACTICE

110. Gestione errori
di una
richiesta
Lambda
● Errori invocazione (prima di
esecuzione): codici errore 4xx-5xx
○ Validità JSON, dimensioni richiesta,
permessi, limite richieste raggiunto
● Errori di funzione (codice Lambda o
runtime): non codici errore ma header
○ Timeout, eccezioni, errori sintassi
Errori invocazione
Errori runtime nodejs

111. Strumenti per
debugging
locale
● AWS SAM
● Serverless Offline (by Serverless
framework)
● Visual Studio Code AWS Toolkit

112. Strumenti per
debugging in
cloud
● Postman per chiamate API
● AWS Lambda Console (permette di
scrivere event object di test per le
funzioni)
● AWS CloudWatch (un log group per
ogni Lambda)

113. Strumenti per
logging
avanzato in
cloud
● AWS X-Ray: dati approfonditi su
eventi/trigger, chiamate API,
esecuzione funzioni, chiamate ai
servizi di destinazione
● Lambda Insights: aggiunge
automaticamente layer a funzioni per
monitoraggio più approfondito tramite
estensione di CloudWatch

114. Riepilogo Best Practice
4. STRUMENTI E BEST PRACTICE

115. Best Practice
per gestione
applicazione in
FaaS
Usare più possibile automazione:
● Usare Infrastructure as Code
● Creare pipeline di deploy
● Monitoraggio da subito, anche come
fonte di eventi
● Automatizzare testing e controlli di
sicurezza
Tutto questo aumenta agilità per
velocizzare sviluppo e feedback loop

116. Best Practice
architettura
Serverless
● Approccio “Serverless-first” per i nuovi
servizi
● Preferire architettura basata su queue
e messaging, per tenere sotto
controllo le invocazioni
● EventBridge per integrazione con
servizi custom e SaaS
● AWS Well Architected Tool: verifiche a
ogni iterazione
Well Architected Tool

117. QA

118. THANK YOU!