Progettare e sviluppare soluzioni basate sulle tecnologie serverless

1. APPLICAZIONI
SERVERLESS CON AWS
Progettare e sviluppare soluzioni
basate sulle tecnologie serverless
10/2020

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. Oggi
● Panoramica su soluzioni disponibili
● Considerazioni sul design
● Demo su concetti e soluzioni
presentati
Domani
● 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. DEFINIZIONE
FaaS/BaaS/IaaS/PaaS
Le promesse di serverless
Use case
2. I PRODOTTI DISPONIBILI
Il mercato serverless
La famiglia AWS serverless
4. STRUMENTI E BEST PRACTICE
Framework e ambienti di sviluppo
Testing
Debug, log, monitoraggio
3. DESIGN E ARCHITETTURA
Strumenti AWS
Performance e Capacity
Deploy e Release
Gestione costi

6. 1. DEFINIZIONE

7. 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

8. 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

9. Serverless
● Creare ed eseguire applicazioni senza dover
gestire i server
● Applicazioni = bundle di una o più funzioni
● Caricate su una piattaforma
● Esecuzioni, scaling e billing basati sulla
precisa richiesta di servizio
CNCF

10. Serverless
● Architettura nativa dei servizi cloud
● Non si deve pensare ai server
● No attività di gestione dell'infrastruttura da
parte dell’utente
● Managed high availability (replica automatica
su AZ multiple)
AWS

11. Serverless
riguarda prima
di tutto
la UX degli
sviluppatori!
● Efficienza nei costi e nell’utilizzo di risorse
(possibile scaling a ZERO)
● Utilizzo (e pagamento) on-demand
● Automazione per scaling e recovery

12. “X as-a-Service”
1. DEFINIZIONE

13. IaaS:
Infrastructure
as a Service
Servizi che permettono tramite API di richiedere
risorse (networking, computing, storage, ecc.) ,
delegando al provider la gestione e la
configurazione dell’infrastruttura

14. PaaS:
Platform as a
Service
Servizi Cloud che permettono di sviluppare,
eseguire e gestire applicazioni rimuovendo la
complessità di creare e mantenere
l’infrastruttura

15. BaaS:
Backend as a
Service
Fornisce alle applicazioni servizi di storage e API
integrate per funzionalità comuni
(autenticazione e gestione utenti, notifiche,
integrazione social network…)

16. FaaS:
Functions as a
Service
Servizio che permette di eseguire e gestire il
codice delle applicazioni come singole funzioni
che sono chiamate attraverso eventi o richieste
HTTP

17. FaaS:
Functions as a
Service
La più importante differenza operativa tra PaaS e
FaaS è lo scaling: che con FaaS può diventare
completamente trasparente per chi usa il
servizio

18. Le promesse di serverless
1. DEFINIZIONE

19. 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

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

21. Promesse da
serverless…
Focus sullo sviluppo del prodotto e sulle
sue caratteristiche uniche, possibilità di
non preoccuparsi di implementazione (e
costi) dei backing services (BaaS)
AWS

22. Promesse da
serverless…
Nessun bisogno di gestire server: il
perimetro di release e deployment è più
circoscritto, riducendo la complessità,
aumentando (potenzialmente) la
frequenza di rilasci e il time-to-market
AWS

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

24. Serverless non
può
promettere…
Esecuzione di comandi di lunga durata

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

26. Serverless non
può
promettere…
#NoOps: i sistemi non richiedono
amministrazione, ma servono
monitoraggio, debug, configurazione…

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

28. Use case
1. DEFINIZIONE

29. Utilizzo incostante

30. Architettura event-driven

31. Architettura microservices con frontend
HTTP-based

32. Integrazione IoT

33. Chatbot e interfaccia vocale

34. Data e media processing
Specialmente in modalità asincrona

35. 2. I PRODOTTI DISPONIBILI

36. Principali prodotti serverless disponibili
2. I PRODOTTI DISPONIBILI

37. Serverless (FaaS) vendor
AWS Lambda
Azure Functions
Google Cloud Functions
IBM Cloud Functions
Oracle Cloud Functions
Cloudflare Workers
Alibaba Cloud Function Compute

38. Fattori nel
confronto di
prodotti
serverless
● Supporto per linguaggi
● Integrazione con altri servizi
(ecosistema vendor)
● Facilità d’uso / Developer UX
● Prestazioni: disponibilità “@Edge” e
tempo di cold-start

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

40. Fattori nel
confronto di
prodotti
serverless
● Limiti
○ Memoria
○ Durata esecuzione
○ Dimensioni payload

41. 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

42. 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

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

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

45. Prodotti serverless AWS
Storage
● S3
Data Store
● DynamoDB (NoSQL)
● Aurora Serverless (RDB)
API
● API Gateway
● AppSync

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

47. Lambda
2. I PRODOTTI DISPONIBILI

48. 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)

49. 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)

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

51. 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

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

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

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

55. DynamoDB
2. I PRODOTTI DISPONIBILI

56. 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”

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

58. API Gateway
2. I PRODOTTI DISPONIBILI

59. API Gateway
● Servizio managed per creare API HTTP
(RESTful), REST, Websocket
● Permette di delegare:
○ Routing
○ Autenticazione
○ CORS
○ Deployment
○ Mapping risorse (es. tabelle
DynamoDB)

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

61. 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

62. Strumenti AWS per lo sviluppo serverless
2. I PRODOTTI DISPONIBILI

63. 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

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

65. 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

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

67. Serverless
Application
Model

68. 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

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

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

71. 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)

72. 3. DESIGN E ARCHITETTURA

73. Performance e capacity
3. DESIGN E ARCHITETTURA

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

75. 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” (timeout per vita di
una funzione: 10, max 15 minuti)
● AWS offre soluzione (per $)

76. 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

77. 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

78. 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

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

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

81. Deployment e release
3. DESIGN E ARCHITETTURA

82. 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)

83. 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

84. 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”)

85. 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

86. 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

87. 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

88. Gestione dei costi
3. DESIGN E ARCHITETTURA

89. 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

90. 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

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

92. 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

93. 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

94. 4. STRUMENTI E BEST PRACTICE

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

96. 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

97. Framework
● Serverless framework
● Serverless Application Model (SAM)
● Spring Cloud Function
● Altri…

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

99. 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)

100. 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

101. IDE/CLI
● AWS SAM CLI
● AWS CLoud9
● Plugin per Eclipse (Java) e Visual
Studio (.NET)
● Visual Studio Code AWS Toolkit

102. Testing
4. STRUMENTI E BEST PRACTICE

103. 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

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

105. Gestione errori
di una
chiamata
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

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

107. 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)

108. 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

109. THANK YOU!