Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Come funziona Lambda
Le funzioni Lambda sono gli elementi costitutivi di base utilizzati per creare applicazioni Lambda. Per scrivere funzioni, è essenziale comprendere i concetti e i componenti fondamentali che costituiscono il modello di programmazione Lambda. Questa sezione ti guiderà attraverso gli elementi fondamentali che devi conoscere per iniziare a creare applicazioni serverless con Lambda.
+ **[Funzioni Lambda e gestori di funzioni](#gettingstarted-concepts-function)**- Una funzione Lambda è un piccolo blocco di codice che viene eseguito in risposta agli eventi. Le funzioni possono essere standard (fino a 15 minuti) o [durevoli](durable-functions.md) (fino a un anno). Le funzioni sono gli elementi costitutivi di base utilizzati per creare applicazioni. I gestori di funzioni sono il punto di ingresso per gli oggetti evento elaborati dal codice funzione Lambda.
+ **[Ambiente di esecuzione Lambda e runtime](#gettingstarted-concepts-runtime)**: gli ambienti di esecuzione Lambda gestiscono le risorse necessarie per eseguire la funzione. Per [funzioni durevoli](durable-functions.md), l'ambiente di esecuzione include funzionalità automatiche di gestione dello stato e checkpoint. I runtime sono gli ambienti specifici del linguaggio in cui vengono eseguite le funzioni.
+ **[Eventi e trigger](#gettingstarted-concepts-event)**- Altri Servizi AWS possono richiamare le tue funzioni in risposta a eventi specifici. Per quanto riguarda le funzioni durevoli, gli eventi possono anche innescare la ripresa dei flussi di lavoro in pausa.
+ **[Autorizzazioni e ruoli Lambda](#gettingstarted-concepts-permissions)**- Controlla chi può accedere alle tue funzioni e con quali altre funzioni possono Servizi AWS interagire. Le funzioni durevoli richiedono autorizzazioni aggiuntive per la gestione dello stato e l'esecuzione estesa.
**Suggerimento**
Se vuoi iniziare a comprendere lo sviluppo serverless più in generale, consulta [Informazioni sulla differenza tra sviluppo tradizionale e serverless](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html) nella *Guida per gi sviluppatori serverless AWS *.
## Funzioni Lambda e gestori di funzioni
In Lambda, le **funzioni** sono gli elementi costitutivi fondamentali utilizzati per creare applicazioni. Una funzione Lambda è una parte di codice che viene eseguita in risposta a eventi, ad esempio un utente che fa clic su un pulsante in un sito Web o un file che viene caricato in un bucket Amazon Simple Storage Service (Amazon S3). Grazie alle funzioni durevoli, il codice può sospendere l'esecuzione tra le fasi, mantenendo automaticamente lo stato, il che le rende ideali per flussi di lavoro di lunga durata come l'elaborazione degli ordini o la moderazione dei contenuti. Puoi pensare a una funzione come a una sorta di programma autonomo con le seguenti proprietà.
Un **gestore di funzioni** Lambda è il metodo nel codice della funzione che elabora gli eventi. Quando una funzione viene eseguita in risposta a un evento, Lambda esegue il gestore delle funzioni. I dati sull'evento che ha causato l'esecuzione della funzione vengono passati direttamente al gestore. Sebbene il codice di una funzione Lambda possa contenere più di un metodo o una funzione, le funzioni Lambda possono avere un solo gestore.
Per creare una funzione Lambda, crea un pacchetto di implementazione contenente il codice funzione e le rispettive dipendenze. Lambda supporta due tipi di pacchetti di implementazione: [archivi di file .zip](configuration-function-zip.md) e [immagini di container](images-create.md).
+ Una funzione ha un lavoro o uno scopo specifico
+ Vengono eseguite solo quando necessario in risposta a eventi specifici
+ Smettono automaticamente di funzionare al termine
## Ambiente di esecuzione Lambda e runtime
Le funzioni Lambda vengono eseguite all'interno di un *[ambiente di esecuzione](lambda-runtime-environment.md)* sicuro e isolato che Lambda gestisce per te. Per [funzioni durevoli](durable-functions.md), l'ambiente di esecuzione include componenti aggiuntivi per la gestione dello stato e il coordinamento del flusso di lavoro. L'ambiente di esecuzione gestisce i processi e le risorse necessari per eseguire la funzione. Quando una funzione viene invocata per la prima volta, Lambda crea un nuovo ambiente di esecuzione in cui eseguire la funzione. Al termine dell'esecuzione della funzione, Lambda non interrompe immediatamente l'ambiente di esecuzione; se la funzione viene invocata nuovamente, Lambda può riutilizzare l'ambiente di esecuzione esistente.
L'ambiente di esecuzione Lambda contiene inoltre un *runtime*, un ambiente specifico al linguaggio che inoltra le informazioni sugli eventi e le risposte tra Lambda e la funzione. Lambda offre una serie di [runtime gestiti](lambda-runtimes.md#runtimes-supported) per i linguaggi di programmazione più diffusi, oppure puoi crearne di tuoi.
Per i runtime festiti, Lambda applica automaticamente aggiornamenti e patch alle funzioni usando il runtime.
## Eventi e trigger
Puoi anche richiamare una funzione Lambda direttamente utilizzando la console Lambda o uno dei [AWS Software [AWS CLI](https://aws.amazon.com/cli/)](https://aws.amazon.com/developer/tools/)Development Kit (). SDKs In un'applicazione di produzione è più comune che una funzione venga richiamata da un'altra Servizio AWS in risposta a un particolare evento. Ad esempio, potresti voler eseguire una funzione ogni volta che un elemento viene aggiunto a una tabella Amazon DynamoDB.
Per fare in modo che la tua funzione risponda agli eventi, configura un **trigger**. Un trigger collega la funzione a un’origine eventi; la funzione può avere più trigger. Quando si verifica un evento, Lambda riceve i dati dell'evento come documento JSON e li converte in un oggetto che il codice può elaborare. Puoi definire il seguente formato JSON per il tuo evento; il runtime Lambda converte questo JSON in un oggetto prima di passarlo al gestore della funzione.
**Example evento Lambda personalizzato**
```
{
"Location": "SEA",
"WeatherData":{
"TemperaturesF":{
"MinTempF": 22,
"MaxTempF": 78
},
"PressuresHPa":{
"MinPressureHPa": 1015,
"MaxPressureHPa": 1027
}
}
}
```
I servizi di streaming e di coda come Amazon Kinesis o Amazon SQS utilizzano [una mappatura delle sorgenti degli eventi anziché un](invocation-eventsourcemapping.md) trigger standard. Gli strumenti di mappatura dell’origine degli eventi analizzano l’origine alla ricerca di dati nuovi, raggruppano i record in batch e invocano quindi la funzione con gli eventi in batch. Per ulteriori informazioni, consulta [In che modo gli strumenti di mappatura dell'origine degli eventi differiscono dai trigger diretti](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference).
Per capire come funziona un trigger, inizia completando il tutorial [Uso di un trigger Amazon S3](with-s3-example.md) oppure, per una panoramica generale sull'uso dei trigger e le istruzioni sulla creazione di un trigger utilizzando la console Lambda, consulta [Integrazione con altri servizi](lambda-services.md).
## Autorizzazioni e ruoli Lambda
Per Lambda, è necessario configurare due tipi principali di [autorizzazioni](permissions-granting-access.md):
+ Autorizzazioni necessarie alla tua funzione per accedere ad altre Servizi AWS
+ Autorizzazioni di cui hanno Servizi AWS bisogno gli altri utenti per accedere alla tua funzione
Le sezioni seguenti descrivono entrambi questi tipi di autorizzazione e illustrano le best practice per applicare le autorizzazioni di privilegio minimo.
### Autorizzazioni per le funzioni di accesso ad altre risorse AWS
Le funzioni Lambda spesso devono accedere ad altre AWS risorse ed eseguire azioni su di esse. Ad esempio, una funzione può leggere elementi da una tabella DynamoDB, archiviare un oggetto in un bucket S3 o scrivere in una coda Amazon SQS. Per concedere alle funzioni le autorizzazioni necessarie per eseguire queste azioni, puoi utilizzare un *[ruolo di esecuzione](lambda-intro-execution-role.md)*.
*Un ruolo di esecuzione Lambda è un tipo speciale di [ruolo AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) (IAM), un'identità che crei nel tuo account a cui sono associate autorizzazioni specifiche definite in una policy.*
Ogni funzione Lambda deve avere un ruolo di esecuzione e un singolo ruolo può essere utilizzato da più di una funzione. Quando viene invocata una funzione, Lambda assume il ruolo di esecuzione della funzione e riceve l'autorizzazione a intraprendere le azioni definite nella policy del ruolo.
Quando crei una funzione nella console Lambda, Lambda crea automaticamente un ruolo di esecuzione per la funzione. La politica del ruolo fornisce alla tua funzione le autorizzazioni di base per scrivere output di log su Amazon CloudWatch Logs. Per autorizzare la funzione a eseguire azioni su altre AWS risorse, devi modificare il ruolo per aggiungere autorizzazioni aggiuntive. Il modo più semplice per aggiungere autorizzazioni consiste nell'utilizzare una policy AWS [gestita](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies). Le policy gestite vengono create e amministrate da AWS e forniscono autorizzazioni per molti casi d'uso comuni. Ad esempio, se la tua funzione esegue operazioni CRUD su una tabella DynamoDB, puoi aggiungere [AmazonDynamoDBFullla politica di accesso al](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) tuo ruolo.
### Autorizzazioni per altri utenti e risorse per accedere alla tua funzione
Per concedere altre Servizio AWS autorizzazioni per accedere alla funzione Lambda, si utilizza una politica basata sulle *[risorse](access-control-resource-based.md)*. In IAM, le policy basate sulle risorse sono collegate a una risorsa (in questo caso, la funzione Lambda) e definiscono chi può accedere alla risorsa e quali azioni può eseguire.
Affinché un'altra Servizio AWS persona possa richiamare la tua funzione tramite un trigger, la politica basata sulle risorse della funzione deve concedere al servizio l'autorizzazione a utilizzare l'azione. `lambda:InvokeFunction` Se crei il trigger utilizzando la console, Lambda aggiunge automaticamente questa autorizzazione per te.
Per concedere l'autorizzazione ad altri AWS utenti ad accedere alla tua funzione, puoi definirla nella politica basata sulle risorse della tua funzione esattamente come per un'altra o risorsa. Servizio AWS Puoi anche utilizzare una *[policy basata sull'identità](access-control-identity-based.md)* associata all'utente.
### Best practice per le autorizzazioni Lambda
Quando imposti le autorizzazioni usando le policy IAM, la [best practice di sicurezza](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) consiste nel concedere le autorizzazioni richieste per eseguire un'attività. Ciò è noto come principio di *privilegio minimo*. Per iniziare a concedere le autorizzazioni per la tua funzione, puoi scegliere di utilizzare una politica gestita. AWS Le policy gestite possono essere il modo più rapido e semplice per concedere le autorizzazioni per eseguire un'attività, ma possono includere anche altre autorizzazioni non necessarie. Man mano che passi dallo sviluppo iniziale al test e alla produzione, ti consigliamo di ridurre le autorizzazioni solo a quelle necessarie definendo [policy personalizzate gestite dal cliente.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)
Lo stesso principio si applica quando si concedono autorizzazioni per accedere alla tua funzione utilizzando una ploicy basata sulle risorse. Ad esempio, se desideri autorizzare Amazon S3 a richiamare la tua funzione, è consigliabile limitare l'accesso ai singoli bucket, o ai bucket in particolare Account AWS, anziché concedere autorizzazioni generali al servizio S3.
# Esecuzione di codice con Lambda
Quando scrivi una funzione Lambda, crei codice che verrà eseguito in un ambiente serverless unico. Comprendere come Lambda esegue effettivamente il codice implica due aspetti chiave: il modello di programmazione che definisce il modo in cui il codice interagisce con Lambda e il ciclo di vita dell'ambiente di esecuzione che determina il modo in cui Lambda gestisce l'ambiente di runtime del codice.
## Il modello di programmazione Lambda
Il modello di programmazione funziona come un insieme comune di regole per il modo in cui Lambda interagisce con il tuo codice, indipendentemente dal fatto che tu stia scrivendo in Python, Java o in qualsiasi altro linguaggio supportato. Il modello di programmazione include il runtime e il gestore.
**Per le funzioni standard:**
1. Lambda riceve un evento.
1. Lambda utilizza il runtime per preparare l'evento in un formato utilizzabile dal codice.
1. Il runtime invia l'evento formattato al gestore.
1. Il tuo gestore elabora l'evento utilizzando il codice che hai scritto.
**Per funzioni durevoli:**
1. Lambda riceve un evento
1. Il runtime prepara sia l'evento che DurableContext
1. Il tuo gestore può:
+ Fasi del processo con checkpoint automatico
+ Metti in pausa l'esecuzione senza consumare risorse
+ Riprendi dall'ultimo checkpoint riuscito
+ Mantieni lo stato tra i passaggi
Essenziale per questo modello è il *gestore* al quale cui Lambda invia gli eventi che devono essere elaborati dal codice. Consideralo come il punto di ingresso per il tuo codice. Quando Lambda riceve un evento, lo trasmette al gestore insieme ad alcune informazioni di contesto. Il gestore esegue quindi il codice per elaborare questi eventi: ad esempio, potrebbe leggere un file quando viene caricato su Amazon S3, analizzare un'immagine o aggiornare un database. Una volta che il codice ha terminato l'elaborazione di un evento, il gestore è pronto per elaborare quello successivo.
## Il modello di esecuzione Lambda
Mentre il modello di programmazione definisce il modo in cui Lambda interagisce con il codice, l'ambiente di esecuzione è il luogo in cui Lambda esegue effettivamente la tua funzione: è uno spazio di calcolo sicuro e isolato creato appositamente per la tua funzione.
**Ogni ambiente segue un ciclo di vita che varia tra funzioni standard e durevoli:**
**Funzioni standard (fino a 15 minuti):**
1. **Inizializzazione:** configurazione dell'ambiente e caricamento del codice
1. **Invocazione:** esecuzione singola del codice della funzione
1. **Arresto: pulizia dell'ambiente**
**Funzioni durevoli (fino a 1 anno):**
1. **Inizializzazione: configurazione** dell'ambiente e dello stato durevole
1. **Invocazione:** passaggi multipli con checkpoint automatico
1. **Stati di attesa:** sospende l'esecuzione senza consumo di risorse
1. **Riprendi: riavvia** dall'ultimo checkpoint
1. **Arresto: pulizia dello stato durevole**
Questo ambiente gestisce aspetti importanti dell'esecuzione della funzione. Fornisce memoria alla funzione, insieme a una directory `/tmp` per l'archiviazione temporanea. **Per Durable Functions, gestisce anche:**
+ Persistenza automatica dello stato tra i passaggi
+ Archiviazione e ripristino dei checkpoint
+ Attendi il coordinamento statale
+ Monitoraggio dei progressi nelle esecuzioni di lunga durata
# Comprendere il modello di programmazione Lambda
Lambda offre due modelli di programmazione: funzioni standard che durano fino a 15 minuti e Durable Functions che possono funzionare fino a un anno. Sebbene entrambi condividano i concetti fondamentali, Durable Functions aggiunge funzionalità per flussi di lavoro di lunga durata e caratterizzati da uno stato.
Lambda fornisce un modello di programmazione comune a tutti i tempi di esecuzione. Il modello di programmazione definisce l'interfaccia tra il codice e il sistema Lambda. Comunica a Lambda il punto di ingresso alla funzione definendo un *gestore* nella configurazione della funzione. Il runtime trasferisce al gestore gli oggetti che contengono l'*evento* di chiamata e il *contesto*, ad esempio il nome della funzione e l'ID della richiesta.
**Per Durable Functions, il gestore riceve anche un oggetto che fornisce: DurableContext **
+ Funzionalità di checkpoint tramite step ()
+ Gestione dello stato di attesa tramite wait () e waitForCallback ()
+ Persistenza automatica dello stato tra le chiamate
Quando l'handler termina l'elaborazione del primo evento, il runtime ne invia un altro. Per Durable Functions, il gestore può sospendere l'esecuzione tra i passaggi e Lambda salverà e ripristinerà automaticamente lo stato quando la funzione riprende. La classe della funzione rimane in memoria, quindi i client e le variabili dichiarate al di fuori del metodo del gestore nel *codice di inizializzazione* possono essere riutilizzati. Per risparmiare tempo di elaborazione sugli eventi successivi, crea risorse riutilizzabili come i client SDK AWS durante l'inizializzazione. Una volta inizializzata, ogni istanza della tua funzione può elaborare migliaia di richieste.
La funzione ha anche accesso allo spazio di archiviazione locale nella directory `/tmp`, una cache transitoria che può essere utilizzata per più invocazioni. Per ulteriori informazioni, consulta [Ambiente di esecuzione](lambda-runtime-environment.md).
Quando la [traccia AWS X-Ray](services-xray.md) è abilitata, il runtime registra sottosegmenti separati per l'inizializzazione e l'esecuzione.
Il runtime acquisisce l'output di registrazione dalla tua funzione e lo invia ad Amazon CloudWatch Logs. Oltre a registrare l'output della funzione, il runtime registra anche le voci all'avvio e alla fine dell'invocazione. Questo include un log del report con l'ID della richiesta, la durata fatturata, la durata di inizializzazione e altri dettagli. Se la funzione genera un errore, il runtime restituisce tale errore all'invoker.
**Nota**
[La registrazione è soggetta alle quote di log. CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) È possibile perdere i dati di log a causa del throttling o, in alcuni casi, quando un'istanza della funzione viene interrotta.
**Principali differenze per le funzioni durevoli:**
+ Lo stato viene mantenuto automaticamente tra i passaggi
+ Le funzioni possono sospendere l'esecuzione senza consumare risorse
+ I passaggi vengono ritentati automaticamente in caso di errore
+ I progressi vengono tracciati tramite checkpoint
Lambda dimensiona la funzione eseguendone altre istanze in base all'aumento della domanda e interrompendo le istanze in base alla diminuzione della domanda. Questo modello porta a variazioni nell'architettura delle applicazioni, come ad esempio:
+ Salvo diversa indicazione, le richieste in entrata possono essere elaborate fuori ordine o simultaneamente.
+ Non fare affidamento sulla durata delle istanze della funzione, ma archivia lo stato dell'applicazione in altri servizi.
+ Utilizza lo storage locale e gli oggetti a livello di classe per migliorare le prestazioni, mantenendo al minimo le dimensioni del pacchetto di distribuzione e la quantità di dati trasferiti nell'ambiente di esecuzione.
Per un'introduzione pratica al modello di programmazione preferito, consulta i seguenti capitoli.
+ [Compilazione di funzioni Lambda con Node.js](lambda-nodejs.md)
+ [Compilazione di funzioni Lambda con Python](lambda-python.md)
+ [Compilazione di funzioni Lambda con Ruby](lambda-ruby.md)
+ [Compilazione di funzioni Lambda con Java](lambda-java.md)
+ [Compilazione di funzioni Lambda con Go](lambda-golang.md)
+ [Compilazione di funzioni Lambda con C\$1](lambda-csharp.md)
+ [Creazione di funzioni Lambda con PowerShell](lambda-powershell.md)
# Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda
Gli ambienti di esecuzione Lambda supportano sia funzioni standard (fino a 15 minuti) che funzioni durevoli (fino a un anno). Sebbene entrambi condividano lo stesso ciclo di vita di base, Durable Functions aggiunge funzionalità di gestione dello stato per flussi di lavoro di lunga durata.
Lambda richiama la funzione in un ambiente di esecuzione, che fornisce un ambiente di runtime sicuro e isolato. L'ambiente di esecuzione gestisce le risorse necessarie per eseguire la funzione. L'ambiente di esecuzione fornisce inoltre il supporto del ciclo di vita per il runtime della funzione e per tutte le [estensioni esterne](lambda-extensions.md) associate alla funzione.
**Per Durable Functions, l'ambiente di esecuzione include componenti aggiuntivi per:**
+ Persistenza dello stato tra i passaggi
+ Gestione dei checkpoint
+ Aspetta il coordinamento dello stato
+ Monitoraggio dei progressi
**Ambiente di esecuzione Lambda Managed Instances**
Se si utilizzano [istanze gestite Lambda](lambda-managed-instances-execution-environment.md), l'ambiente di esecuzione presenta differenze importanti rispetto alle funzioni Lambda (predefinite). Le istanze gestite supportano chiamate simultanee, utilizzano un modello di ciclo di vita diverso e vengono eseguite su un'infrastruttura di proprietà del cliente. Per informazioni dettagliate sull'ambiente di esecuzione delle istanze gestite, vedere. [Comprendere l'ambiente di esecuzione di Lambda Managed Instances](lambda-managed-instances-execution-environment.md)
Il runtime della funzione comunica con Lambda e usa l'[API Runtime](runtimes-api.md). Le estensioni comunicano con Lambda utilizzando le [API estensioni](runtimes-extensions-api.md). Le estensioni possono anche ricevere messaggi di log e altra telemetria dalla funzione tramite l'[API di telemetria](telemetry-api.md).
![\[Diagramma di architettura dell'ambiente di esecuzione.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
Quando si crea la funzione Lambda, si specificano le informazioni di configurazione, ad esempio la quantità di memoria disponibile e il tempo massimo di esecuzione consentito per la funzione. Lambda utilizza queste informazioni per impostare l'ambiente di esecuzione.
Il runtime della funzione e ogni estensione esterna sono processi eseguiti all'interno dell'ambiente di esecuzione. Le autorizzazioni, le risorse, le credenziali e le variabili di ambiente sono condivise tra la funzione e le estensioni.
**Topics**
+ [
## Ciclo di vita dell'ambiente di esecuzione Lambda
](#runtimes-lifecycle)
+ [
## Avvii a freddo e latenza
](#cold-start-latency)
+ [
## Riduzione degli avvii a freddo con la simultaneità fornita
](#cold-starts-pc)
+ [
## Ottimizzazione dell'inizializzazione statica
](#static-initialization)
## Ciclo di vita dell'ambiente di esecuzione Lambda
![\[Fasi del ciclo di vita Lambda: Init, Invoke, Shutdown\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/Overview-Successful-Invokes.png)
Ogni fase inizia con un evento che Lambda invia al runtime e a tutte le estensioni registrate. Il runtime e ogni estensione indicano il completamento inviando una richiesta API `Next`. Lambda congela l'ambiente di esecuzione quando il runtime e ogni estensione sono stati completati e non ci sono eventi in sospeso.
**Le fasi del ciclo di vita di Durable Functions includono:**
+ **Init:** inizializzazione standard più configurazione durevole dello stato
+ **Invoke:** può includere esecuzioni in più fasi con checkpoint automatico
+ **Attendi:** la funzione può mettere in pausa l'esecuzione senza consumare risorse
+ **Riprendi: la** funzione viene riavviata dall'ultimo checkpoint
+ **Chiusura: ripulitura dello stato e delle risorse durevoli**
**Topics**
+ [
### Fase di init
](#runtimes-lifecycle-ib)
+ [
### Errori durante la fase di inizializzazione
](#runtimes-lifecycle-init-errors)
+ [
### Fase di ripristino (solo Lambda SnapStart )
](#runtimes-lifecycle-restore)
+ [
### Invoca fase
](#runtimes-lifecycle-invoke)
+ [
### Errori durante la fase di richiamo
](#runtimes-lifecycle-invoke-with-errors)
+ [
### Fase di arresto
](#runtimes-lifecycle-shutdown)
### Fase di init
Nella fase `Init`, Lambda esegue tre incarichi:
+ Avvia tutte le estensioni (`Extension init`)
+ Esegue il bootstrap del runtime (`Runtime init`)
+ Esegue il codice statico della funzione (`Function init`)
+ Esegui qualsiasi [hook](snapstart-runtime-hooks.md) di runtime before-checkpoint (solo Lambda) SnapStart
La fase `Init` termina quando il runtime e tutte le estensioni segnalano che sono pronti inviando una richiesta `Next` API. La fase `Init` è limitata a 10 secondi. Se tutte e tre le attività non vengono completate entro 10 secondi, Lambda ritenta la fase `Init` al momento della prima chiamata di funzione con timeout della funzione configurata.
Quando [Lambda SnapStart](snapstart.md) è attivato, la fase `Init` si verifica quando si pubblica una versione della funzione. Lambda salva uno snapshot della memoria e dello stato del disco dell'ambiente di esecuzione inizializzato, mantiene lo snapshot crittografato e lo memorizza nella cache per l'accesso a bassa latenza. Se disponi di un [hook di runtime](snapstart-runtime-hooks.md) prima del checkpoint, il codice viene eseguito alla fine della fase `Init`.
**Nota**
Il timeout di 10 secondi non si applica alle funzioni che utilizzano la concorrenza fornita SnapStart o le istanze gestite Lambda. Per le funzioni di provisioning, concorrenza e istanze gestite SnapStart, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il timeout della funzione configurato (massimo 900 secondi), a seconda di quale dei due valori sia più elevato.
Quando utilizzi la [simultaneità fornita](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html), Lambda inizializza l'ambiente di esecuzione quando configuri le impostazioni del PC per una funzione. Lambda, inoltre, garantisce che gli ambienti di esecuzione inizializzati siano sempre disponibili prima delle invocazioni. Potrebbero verificarsi lacune tra l'invocazione della funzione e le fasi di inizializzazione. A seconda del runtime della funzione e della configurazione della memoria, può anche verificarsi una latenza delle variabili nella prima invocazione in un ambiente di esecuzione inizializzato.
Per le funzioni che utilizzano la simultaneità on demand, Lambda può inizializzare occasionalmente gli ambienti di esecuzione prima delle richieste di invocazione. Quando ciò si verifica, puoi riscontrare una lacuna temporale tra le fasi di inizializzazione e invocazione della funzione. È preferibile non acquisire dipendenza da questo comportamento.
### Errori durante la fase di inizializzazione
Se una funzione si arresta in modo anomalo o si verifica un timeout durante la fase `Init`, Lambda emette informazioni sull'errore nel log `INIT_REPORT`.
**Example — Log INIT\$1REPORT per il timeout**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
```
**Example — Log INIT\$1REPORT per gli errori di estensione**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash
```
Se la `Init` fase ha esito positivo, Lambda non emette il `INIT_REPORT` registro a meno che non [SnapStart](snapstart.md)sia abilitata la [concorrenza fornita.](provisioned-concurrency.md) SnapStart e le funzioni di concorrenza predisposte vengono sempre emesse. `INIT_REPORT` Per ulteriori informazioni, consulta [Monitoraggio per Lambda SnapStart](snapstart-monitoring.md).
### Fase di ripristino (solo Lambda SnapStart )
Quando richiami una [SnapStart](snapstart.md)funzione per la prima volta e man mano che la funzione aumenta, Lambda riprende i nuovi ambienti di esecuzione dall'istantanea persistente invece di inizializzare la funzione da zero. Se disponi di un [hook di runtime](snapstart-runtime-hooks.md) dopo il ripristino, il codice viene eseguito alla fine della fase `Restore`. Ti sarà addebitata la durata degli hook di runtime dopo il ripristino. Il runtime deve essere caricato e gli hook di runtime dopo il ripristino devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un. SnapStartTimeoutException Al termine della fase `Restore`, Lambda chiama il gestore della funzione ([Invoca fase](#runtimes-lifecycle-invoke)).
#### Errori durante la fase di ripristino
Se la fase `Restore` fallisce, Lambda emette informazioni sull'errore nel log `RESTORE_REPORT`.
**Example — Log RESTORE\$1REPORT per il timeout**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
```
**Example — Log RESTORE\$1REPORT per gli errori dell'hook di runtime**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError
```
Per ulteriori informazioni sul log `RESTORE_REPORT`, consulta la pagina [Monitoraggio per Lambda SnapStart](snapstart-monitoring.md).
### Invoca fase
Quando una funzione Lambda viene richiamata in risposta a una richiesta API `Next`, Lambda invia un evento `Invoke` al runtime e a ogni estensione.
L'impostazione di timeout della funzione limita la durata dell'intera fase `Invoke`. Ad esempio, se si imposta il timeout della funzione come 360 secondi, la funzione e tutte le estensioni devono essere completate entro 360 secondi. Si noti che non esiste una fase post-richiamo indipendente. La durata è la somma di tutto il tempo di chiamata (runtime \$1 estensioni) e non viene calcolata fino a quando la funzione e tutte le estensioni non hanno terminato l'esecuzione.
La fase di richiamo termina dopo il runtime e tutte le estensioni segnalano che vengono eseguite inviando una richiesta `Next` API.
### Errori durante la fase di richiamo
Se la funzione Lambda si arresta in modo anomalo o si verifica un timeout durante la fase `Invoke`, Lambda reimposta l'ambiente di esecuzione. Il diagramma seguente mostra il comportamento dell'ambiente di esecuzione Lambda in caso di errore di invocazione:
![\[Esempio di ambiente di esecuzione: Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
Nel diagramma precedente:
+ La prima è la fase **INIT** e viene eseguita senza errori.
+ La seconda è la fase **INVOKE** e viene eseguita senza errori.
+ A un certo punto, supponiamo che la funzione riscontri un errore di richiamo (le cause più comuni includono timeout delle funzioni, errori di runtime, esaurimento della memoria, problemi di connettività VPC, errori di autorizzazione, limiti di concorrenza e vari problemi di configurazione). Per un elenco completo dei possibili errori di chiamata, vedere. [Risoluzione dei problemi di invocazione in Lambda](troubleshooting-invocation.md) La terza fase, denominata **INVOKE WITH ERROR**, mostra questo scenario. In questo caso, il servizio Lambda esegue un ripristino. Il reset si comporta come un evento `Shutdown`. Innanzitutto Lambda chiude il runtime, poi invia un evento `Shutdown` a ogni estensione esterna registrata. L'evento include il motivo dell'arresto. Se questo ambiente viene utilizzato per una nuova chiamata, Lambda re-inizializza l'estensione e il runtime insieme alla chiamata successiva.
Tieni presente che il reset Lambda non cancella il contenuto della directory `/tmp` prima della fase di init successiva. Questo comportamento è coerente con la normale fase di arresto.
**Nota**
AWS sta attualmente implementando modifiche al servizio Lambda. A causa di queste modifiche, potresti notare piccole differenze tra la struttura e il contenuto dei messaggi di log di sistema e dei segmenti di traccia emessi da diverse funzioni Lambda nel tuo Account AWS.
Se la configurazione del registro di sistema della funzione è impostata su testo semplice, questa modifica influisce sui messaggi di registro acquisiti in CloudWatch Logs quando la funzione riscontra un errore di richiamo. Gli esempi seguenti mostrano gli output dei log nei formati vecchi e nuovi.
Queste modifiche verranno implementate nelle prossime settimane e tutte le funzioni, Regioni AWS ad eccezione della Cina e delle GovCloud regioni, passeranno all'utilizzo dei messaggi di registro e dei segmenti di traccia di nuovo formato.
**Example CloudWatch Registra l'output dei log (arresto anomalo del runtime o dell'estensione): vecchio stile**
```
START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
```
**Example CloudWatch Registra l'output del log (timeout della funzione) - vecchio stile**
```
START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3117 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms
```
Il nuovo formato per CloudWatch i log include un `status` campo aggiuntivo nella riga. `REPORT` In caso di arresto anomalo del runtime o dell'estensione, la riga `REPORT` include anche un campo `ErrorType`.
**Example CloudWatch Registra l'output dei log (runtime o crash dell'estensione): nuovo stile**
```
START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 214 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
```
**Example CloudWatch Registra l'output del log (timeout della funzione) - nuovo stile**
```
START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout
```
+ La quarta fase rappresenta la fase **INVOKE**, immediatamente successiva a un errore di chiamata. In questo caso Lambda inizializza nuovamente l'ambiente eseguendo nuovamente la fase **INIT**. Questa operazione è chiamata *inizializzazione soppressa*. **Quando si verificano init soppressi, Lambda non riporta esplicitamente una fase INIT aggiuntiva nei log.** CloudWatch Infatti potresti notare che la durata nella riga REPORT include una durata **INIT** aggiuntiva \$1 la durata **INVOKE**. Ad esempio, supponiamo di visualizzare i seguenti log in: CloudWatch
```
2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST
2022-12-20T01:00:02.500-08:00 END RequestId: XXX
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB
```
In questo esempio, la differenza tra i timestamp REPORT e START è di 2,5 secondi. Ciò non corrisponde alla durata riportata di 3022,91 millisecondi, perché la durata della **INIT** (inizializzazione soppressa) aggiuntiva eseguita da Lambda non viene tenuta in conto. Da questo esempio puoi capire che la fase **INVOKE** effettiva ha richiesto 2,5 secondi.
Per ulteriori informazioni su questo comportamento, puoi utilizzare il [Accesso ai dati di telemetria in tempo reale per le estensioni tramite l'API Telemetry](telemetry-api.md). L'API di telemetria produce gli eventi `INIT_START`, `INIT_RUNTIME_DONE` e `INIT_REPORT` insieme a `phase=invoke` ogni volta che le inizializzazioni vengono soppresse tra le fasi di invocazione.
+ La quinta fase rappresenta la fase **SHUTDOWN**, che viene eseguita senza errori.
### Fase di arresto
Quando Lambda sta per chiudere il runtime, invia un evento `Shutdown` a ciascuna estensione esterna registrata. Le estensioni possono utilizzare questo tempo per le attività di pulizia finali. L'evento `Shutdown` è una risposta a una richiesta API `Next`.
**Limite di durata**: la durata massima della fase `Shutdown` dipende dalla configurazione delle estensioni registrate:
+ 0 ms: funzione senza estensioni registrate
+ 500 ms: funzione con estensione interna registrata
+ 2.000 ms: funzione con una o più estensioni esterne registrate
Se il runtime o un'estensione non risponde all'evento `Shutdown` entro il limite, Lambda termina il processo utilizzando un segnale `SIGKILL`.
Dopo che la funzione e tutte le estensioni sono state completate, Lambda mantiene l'ambiente di esecuzione per qualche tempo in previsione di un'altra chiamata di funzione. Tuttavia, Lambda termina gli ambienti di esecuzione ogni poche ore per consentire gli aggiornamenti e la manutenzione del runtime, anche per le funzioni che vengono richiamate continuamente. Non si deve dare per scontato che l'ambiente di esecuzione persista all'infinito. Per ulteriori informazioni, consulta [Implementazione stateless nelle funzioni](concepts-application-design.md#statelessness-functions).
Quando la funzione viene richiamata nuovamente, Lambda sblocca l'ambiente per il riutilizzo. Il riutilizzo dell'ambiente di esecuzione ha le seguenti implicazioni:
+ Gli oggetti dichiarati al di fuori del metodo del gestore della funzione rimangono inizializzati, fornendo ulteriore ottimizzazione quando la funzione viene nuovamente invocata. Ad esempio, se la funzione Lambda stabilisce la connessione a un database, nelle invocazioni successive viene utilizzata la connessione originaria anziché stabilirne un'altra. È consigliabile aggiungere al codice una logica per verificare l'esistenza di una connessione prima che ne venga stabilita una nuova.
+ Ogni ambiente di esecuzione fornisce da 512 MB a 10.240 MB con incrementi di 1 MB di spazio su disco nella directory `/tmp`. Il contenuto della directory rimane quando il contesto di esecuzione è bloccato, fornendo così una cache transitoria utilizzabile per più invocazioni. È possibile aggiungere ulteriore codice per verificare se la cache contiene i dati memorizzati. Per ulteriori informazioni sui limiti delle dimensioni della distribuzione, vedere [Quote di LambdaQuote di Lambda](gettingstarted-limits.md).
+ Processi in background o callback che sono stati avviati dalla funzione Lambda e che non sono stati completati quando la funzione è terminata; riprendere se Lambda riutilizza l'ambiente di esecuzione. È necessario accertarsi che tutti i processi in background o le callback nel codice vengano completate prima che il codice sia terminato.
## Avvii a freddo e latenza
Quando Lambda riceve una richiesta di esecuzione di una funzione tramite l'API Lambda, il servizio prepara innanzitutto un ambiente di esecuzione. Durante questa fase di inizializzazione, il servizio scarica il codice, avvia l'ambiente ed esegue qualsiasi codice di inizializzazione al di fuori del gestore principale. Infine, Lambda esegue il codice del gestore.
![\[ottimizzazione delle prestazioni (figura 1)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/perf-optimize-figure-1.png)
In questo diagramma, i primi due passaggi del download del codice e della configurazione dell'ambiente vengono spesso definiti «avvio a freddo». [Questo tempo ti viene addebitato](https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/) e ciò aggiunge latenza alla durata complessiva della chiamata.
Una volta completata la chiamata, l'ambiente di esecuzione viene bloccato. Per migliorare la gestione delle risorse e le prestazioni, Lambda conserva l'ambiente di esecuzione per un periodo di tempo. Durante questo periodo, se arriva un'altra richiesta per la stessa funzione, Lambda può riutilizzare l'ambiente. Questa seconda richiesta in genere termina più rapidamente, poiché l'ambiente di esecuzione è già completamente configurato. Questo procedimento è chiamato "avvio a caldo".
Gli avviamenti a freddo si verificano in genere in meno dell'1% delle invocazioni. La durata di un avvio a freddo varia da meno di 100 ms a oltre 1 secondo. In generale, gli avviamenti a freddo sono in genere più comuni nelle funzioni di sviluppo e test rispetto ai carichi di lavoro di produzione. Questo perché le funzioni di sviluppo e test vengono in genere richiamate meno frequentemente.
## Riduzione degli avvii a freddo con la simultaneità fornita
Se hai bisogno di orari di inizio delle funzioni prevedibili per il tuo carico di lavoro, la [simultaneità fornita](provisioned-concurrency.md) è la soluzione consigliata per garantire la latenza più bassa possibile. Questa funzionalità preinizializza gli ambienti di esecuzione, riducendo gli avviamenti a freddo.
Ad esempio, una funzione con una concomitanza assegnata di 6 dispone di 6 ambienti di esecuzione preriscaldati.
![\[ottimizzazione delle prestazioni (figura 4)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/perf-optimize-figure-4.png)
## Ottimizzazione dell'inizializzazione statica
L'inizializzazione statica avviene prima che il codice dell'handler inizi a essere eseguito in una funzione. Questo è il codice di inizializzazione fornito dall'utente, esterno al gestore principale. Questo codice viene spesso utilizzato per importare librerie e dipendenze, impostare configurazioni e inizializzare connessioni ad altri servizi.
Il seguente esempio in Python mostra l'importazione e la configurazione dei moduli e la creazione del client Amazon S3 durante la fase di inizializzazione, prima che la funzione `lambda_handler` venga eseguita durante la fase di invocazione.
```
import os
import json
import cv2
import logging
import boto3
s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
# Handler logic...
```
Il principale fattore di latenza prima dell'esecuzione della funzione proviene dal codice di inizializzazione. Questo codice viene eseguito quando viene creato per la prima volta un nuovo ambiente di esecuzione. Il codice di inizializzazione non viene eseguito nuovamente se una invocazione utilizza un ambiente di esecuzione caldo. I fattori che influiscono sulla latenza del codice di inizializzazione includono:
+ La dimensione del pacchetto di funzioni, in termini di librerie e dipendenze importate e livelli Lambda.
+ La quantità di codice e la procedura di inizializzazione.
+ Le prestazioni delle librerie e di altri servizi nella configurazione di connessioni e altre risorse.
Esistono diversi passaggi che gli sviluppatori possono adottare per ottimizzare la latenza di inizializzazione statica. Se una funzione ha molti oggetti e connessioni, potresti essere in grado di riprogettare una singola funzione in più funzioni specializzate. Questi sono singolarmente più piccoli e ciascuno ha meno codice di inizializzazione.
È importante che le funzioni importino solo le librerie e le dipendenze di cui hanno bisogno. Ad esempio, se utilizzi solo Amazon DynamoDB AWS nell'SDK, puoi richiedere un servizio individuale anziché l'intero SDK. Confronta i tre esempi seguenti:
```
// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')
// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')
// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)
```
L'inizializzazione statica è spesso anche il posto migliore per aprire connessioni al database per consentire a una funzione di riutilizzare le connessioni su più chiamate allo stesso ambiente di esecuzione. Tuttavia, è possibile che nella funzione sia presente un numero elevato di oggetti utilizzati solo in determinati percorsi di esecuzione. In questo caso, puoi caricare lentamente le variabili nell'ambito globale per ridurre la durata dell'inizializzazione statica.
Evita le variabili globali per informazioni specifiche del contesto. Se la funzione ha una variabile globale che viene utilizzata solo per la durata di una singola invocazione e viene reimpostata per l'invocazione successiva, utilizza un ambito di variabile locale per l'handler. In questo modo non solo si evitano perdite di variabili globali tra le invocazioni, ma si migliorano anche le prestazioni dell'inizializzazione statica.
# Creazione di architetture basate sugli eventi con Lambda
Un evento è tutto ciò che attiva l'esecuzione di una funzione Lambda. Gli eventi possono attivare una funzione Lambda in due modi: tramite invocazione diretta (push) e mappatura delle sorgenti degli eventi (pull).
Molti AWS servizi possono richiamare direttamente le funzioni Lambda. Questi servizi *inviano* eventi alla tua funzione Lambda. Gli eventi che attivano le funzioni possono essere praticamente qualsiasi cosa, da una richiesta HTTP tramite API Gateway, una pianificazione gestita da una EventBridge regola, un AWS IoT evento o un evento Amazon S3. Con lo strumento di mappatura dell'origine degli eventi, Lambda recupera (*pull*) attivamente gli eventi da una coda o da un flusso. Puoi configurare Lambda per verificare la presenza di eventi da un servizio supportato e Lambda gestisce il polling e l'invocazione della tua funzione.
Quando passati alla funzione, gli eventi sono strutturati nel formato JSON. La struttura JSON varia a seconda del servizio che la genera e del tipo di evento. Mentre le chiamate alle funzioni Lambda standard possono durare fino a 15 minuti (o fino a un anno con funzioni [durevoli)](durable-functions.md), Lambda è più adatta per chiamate brevi che durano un secondo o meno. Ciò è particolarmente vero per le architetture basate sugli eventi, in cui ogni funzione Lambda viene trattata come un microservizio responsabile dell'esecuzione di una serie ristretta di istruzioni specifiche.
**Nota**
Le architetture basate sugli eventi comunicano tra diversi sistemi utilizzando le reti, che introducono una latenza variabile. Per carichi di lavoro che richiedono una latenza molto bassa, come i sistemi di trading in tempo reale, questo design potrebbe non essere la scelta migliore. Tuttavia, per carichi di lavoro altamente scalabili e disponibili o con schemi di traffico imprevedibili, le architetture basate sugli eventi possono fornire un modo efficace per soddisfare queste esigenze.
**Topics**
+ [
## Vantaggi delle architetture basate sugli eventi
](#event-driven-benefits)
+ [
## Compromessi delle architetture basate sugli eventi
](#event-driven-tradeoffs)
+ [
## Anti-modelli nelle applicazioni basate su Lambda e sugli eventi
](#event-driven-anti-patterns)
## Vantaggi delle architetture basate sugli eventi
Lambda supporta due metodi di invocazione nelle architetture basate sugli eventi:
1. Invocazione diretta (metodo push): i AWS servizi attivano direttamente le funzioni Lambda. Esempio:
+ Amazon S3 attiva una funzione quando viene caricato un file
+ API Gateway attiva una funzione quando riceve una richiesta HTTP
1. Strumento di mappatura dell'origine degli eventi (metodo pull): Lambda recupera gli eventi e richiama le funzioni. Esempio:
+ Lambda recupera i messaggi da una coda Amazon SQS e invoca una funzione
+ Lambda legge i record da un flusso DynamoDB e invoca una funzione
Entrambi i metodi contribuiscono ai vantaggi delle architetture basate sugli eventi, come descritto di seguito.
### Sostituzione di polling e webhook con eventi
Molte architetture tradizionali utilizzano meccanismi di polling e webhook per comunicare lo stato tra diversi componenti. Il polling può essere molto inefficiente per il recupero degli aggiornamenti poiché esiste un ritardo tra la disponibilità di nuovi dati e la sincronizzazione con i servizi a valle. I webhook non sono sempre supportati da altri microservizi con cui si desidera integrarsi. Potrebbero inoltre richiedere configurazioni di autorizzazione e autenticazione personalizzate. In entrambi i casi, questi metodi di integrazione sono difficili da scalare su richiesta senza ulteriore lavoro da parte dei team di sviluppo.
![\[architetture basate sugli eventi (figura 7)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-7.png)
Entrambi questi meccanismi possono essere sostituiti da eventi che possono essere filtrati, indirizzati e trasferiti a valle verso l'utilizzo di microservizi. Questo approccio può comportare un minore consumo di larghezza di banda, un minore utilizzo della CPU e, potenzialmente, una riduzione dei costi. Queste architetture possono anche ridurre la complessità, poiché ogni unità funzionale è più piccola e spesso contiene meno codice.
![\[architetture basate sugli eventi (figura 8)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-8.png)
Le architetture basate sugli eventi possono anche semplificare la progettazione dei near-real-time sistemi, aiutando le organizzazioni ad abbandonare l'elaborazione basata su batch. Gli eventi vengono generati nel momento in cui lo stato dell'applicazione cambia, quindi il codice personalizzato di un microservizio deve essere progettato per gestire l'elaborazione di un singolo evento. Poiché la scalabilità è gestita dal servizio Lambda, questa architettura può gestire aumenti significativi del traffico senza modificare il codice personalizzato. Man mano che gli eventi aumentano, aumenta anche il livello di elaborazione che elabora gli eventi.
### Riduzione della complessità
I microservizi consentono a sviluppatori e architetti di semplificare flussi di lavoro complessi. Ad esempio, un monolite di e-commerce può essere suddiviso in processi di accettazione degli ordini e pagamento con servizi di inventario, evasione e contabilità separati. Ciò che potrebbe essere complesso da gestire e orchestrare in un monolite diventa una serie di servizi disaccoppiati che comunicano in modo asincrono con gli eventi.
![\[architetture basate sugli eventi (figura 9)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-9.png)
Questo approccio consente inoltre di assemblare servizi che elaborano i dati a velocità diverse. In questo caso, un microservizio di accettazione degli ordini può archiviare volumi elevati di ordini in entrata inserendo nel buffer i messaggi in una coda Amazon SQS.
Un servizio di elaborazione dei pagamenti, che in genere è più lento a causa della complessità della gestione dei pagamenti, può ricevere un flusso costante di messaggi dalla coda di Amazon SQS. Può orchestrare complesse logiche di gestione dei tentativi e degli errori utilizzando AWS Step Functions e coordinare flussi di lavoro di pagamento attivi per centinaia di migliaia di ordini.
**Approccio alternativo:** per l'orchestrazione utilizzando linguaggi di programmazione standard, puoi utilizzare le funzioni durevoli [Lambda](durable-functions.md). Le funzioni durevoli consentono di scrivere l'accettazione degli ordini, l'elaborazione dei pagamenti e la logica di notifica in codice con checkpoint e riprova automatici. Questo approccio funziona bene quando il flusso di lavoro coinvolge principalmente funzioni Lambda e si preferisce mantenere la logica di orchestrazione nel codice.
### Migliorare la scalabilità e l'estensibilità
I microservizi generano eventi che in genere vengono pubblicati su servizi di messaggistica come Amazon SNS e Amazon SQS. Questi si comportano come un buffer elastico tra i microservizi e aiutano a gestire la scalabilità quando il traffico aumenta. Servizi come Amazon EventBridge possono quindi filtrare e indirizzare i messaggi in base al contenuto dell'evento, come definito nelle regole. Di conseguenza, le applicazioni basate sugli eventi possono essere più scalabili e offrire una maggiore ridondanza rispetto alle applicazioni monolitiche.
Questo sistema è inoltre altamente estensibile e consente ad altri team di estendere le funzionalità e aggiungere funzionalità senza influire sui microservizi di elaborazione degli ordini e di elaborazione dei pagamenti. Pubblicando eventi utilizzando EventBridge, questa applicazione si integra con i sistemi esistenti, come il microservizio di inventario, ma consente anche l'integrazione di qualsiasi applicazione futura come consumatore di eventi. I produttori di eventi non conoscono gli utenti di eventi, il che può contribuire a semplificare la logica dei microservizi.
## Compromessi delle architetture basate sugli eventi
### Latenza variabile
A differenza delle applicazioni monolitiche, che possono elaborare tutto all'interno dello stesso spazio di memoria su un singolo dispositivo, le applicazioni basate sugli eventi comunicano attraverso le reti. Questo design introduce una latenza variabile. Sebbene sia possibile progettare le applicazioni per ridurre al minimo la latenza, le applicazioni monolitiche possono quasi sempre essere ottimizzate per una latenza inferiore a scapito della scalabilità e della disponibilità.
I carichi di lavoro che richiedono prestazioni costanti a bassa latenza, come le applicazioni di trading ad alta frequenza nelle banche o l'automazione robotica inferiore al millisecondo nei magazzini, non sono buoni candidati per l'architettura basata sugli eventi.
### Consistenza finale
Un evento rappresenta un cambiamento di stato e, poiché molti eventi fluiscono attraverso diversi servizi di un'architettura in un dato momento, tali carichi di lavoro alla fine sono [spesso coerenti](https://en.wikipedia.org/wiki/Eventual_consistency). Ciò rende più complessa l'elaborazione delle transazioni, la gestione dei duplicati o la determinazione dell'esatto stato generale di un sistema.
Molti carichi di lavoro contengono una combinazione di requisiti che alla fine sono coerenti (ad esempio, gli ordini totali nell'ora corrente) o fortemente coerenti (ad esempio, l'inventario corrente). Per i carichi di lavoro che richiedono una forte coerenza dei dati, esistono modelli di architettura a supporto di questa funzionalità. Esempio:
+ DynamoDB è in grado di fornire una [elevata consistenza di lettura](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html), a volte con una latenza più elevata, consumando un throughput maggiore rispetto alla modalità predefinita. DynamoDB può anche [supportare le transazioni](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html) per aiutare a mantenere la coerenza dei dati.
+ Puoi utilizzare Amazon RDS per funzionalità che richiedono [proprietà ACID](https://en.wikipedia.org/wiki/ACID), sebbene qualsiasi database relazionale sia generalmente meno scalabile di database NoSQL come DynamoDB. [Server proxy per Amazon RDS](https://aws.amazon.com/rds/proxy/) può aiutare a gestire il pooling e la scalabilità delle connessioni per utenti effimeri come le funzioni Lambda.
Le architetture basate sugli eventi sono generalmente progettate sulla base di singoli eventi anziché su grandi quantità di dati. In genere, i flussi di lavoro sono progettati per gestire le fasi di un singolo evento o flusso di esecuzione anziché operare su più eventi contemporaneamente. In modalità serverless, l'elaborazione degli eventi in tempo reale è preferita all'elaborazione in batch: i batch devono essere sostituiti con molti aggiornamenti incrementali più piccoli. Se da un lato ciò può rendere i carichi di lavoro più disponibili e scalabili, dall'altro rende più difficile per gli eventi conoscere altri eventi.
### Restituzione di valori ai chiamanti
In molti casi, le applicazioni basate su eventi sono asincrone. Ciò significa che i servizi di chiamata non attendono le richieste da altri servizi prima di continuare con altre attività. Questa è una caratteristica fondamentale delle architetture basate sugli eventi che consente scalabilità e flessibilità. Significa anche che il passaggio dei valori restituiti o del risultato di un flusso di lavoro è più complesso rispetto ai flussi di esecuzione sincroni.
La maggior parte delle invocazioni Lambda nei sistemi di produzione sono [asincrone](invocation-async.md) e rispondono agli eventi di servizi come Amazon S3 o Amazon SQS. In questi casi, il successo o il fallimento dell'elaborazione di un evento è spesso più importante della restituzione di un valore. In Lambda vengono fornite funzionalità come [dead letter queues](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) (DLQs) per garantire che sia possibile identificare e riprovare gli eventi non riusciti, senza dover avvisare il chiamante.
### Esecuzione del debug tra servizi e funzioni
Il debug di sistemi basati sugli eventi è inoltre diverso rispetto a un'applicazione monolitica. Poiché diversi sistemi e servizi trasmettono eventi, non è possibile registrare e riprodurre lo stato esatto di più servizi quando si verifica un errore. Poiché ogni invocazione di servizio e funzione ha file di log separati, può essere più complicato determinare cosa è successo a un evento specifico che ha causato un errore.
Esistono tre requisiti importanti per creare un approccio di debug efficace nei sistemi basati sugli eventi. Innanzitutto, è fondamentale disporre di un sistema di registrazione robusto, che viene fornito attraverso diversi AWS servizi e integrato nelle funzioni Lambda da Amazon. CloudWatch In secondo luogo, in questi sistemi è importante garantire che ogni evento abbia un identificatore di transazione registrato in ogni fase della transazione, per facilitare la ricerca nei log.
Infine, si consiglia vivamente di automatizzare l'analisi e l'analisi dei log utilizzando un servizio di debug e monitoraggio come AWS X-Ray. Ciò può consumare i log di più invocazioni Lambda e servizi, rendendo molto più semplice individuare la causa principale dei problemi. Consulta la [procedura dettagliata sulla risoluzione dei problemi](lambda-troubleshooting.md) per una descrizione approfondita dell'utilizzo di X-Ray per la risoluzione dei problemi.
## Anti-modelli nelle applicazioni basate su Lambda e sugli eventi
Quando crei architetture basate sugli eventi con Lambda, evita i seguenti anti-pattern comuni. Questi modelli funzionano ma possono aumentare i costi e la complessità.
### Il monolite Lambda
In molte applicazioni migrate da server tradizionali, come istanze Amazon EC2 o applicazioni Elastic Beanstalk, gli sviluppatori usano un approccio lift and shift per il codice esistente. Spesso, ciò si traduce in una singola funzione Lambda che contiene tutta la logica dell'applicazione attivata per tutti gli eventi. Per un'applicazione Web di base, una funzione Lambda monolitica gestirebbe tutti i percorsi API Gateway e si integrerebbe con tutte le risorse downstream necessarie.
![\[architetture basate sugli eventi (figura 13)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-13.png)
Questo approccio presenta diversi inconvenienti:
+ **Dimensione del pacchetto**: la funzione Lambda potrebbe essere molto più grande perché contiene tutto il codice possibile per tutti i percorsi, il che rende più lenta l'esecuzione del servizio Lambda.
+ **Difficile applicare il privilegio minimo**: il [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione deve consentire le autorizzazioni a tutte le risorse necessarie per tutti i percorsi, rendendo le autorizzazioni molto ampie. Si tratta di un problema di sicurezza. Molti percorsi nel monolite funzionale non necessitano di tutte le autorizzazioni concesse.
+ **Più difficile da aggiornare**: in un sistema di produzione, qualsiasi aggiornamento alla singola funzione è più rischioso e potrebbe causare l'interruzione dell'intera applicazione. L'aggiornamento di un singolo percorso nella funzione Lambda è un aggiornamento dell'intera funzione.
+ **Più difficile da gestire**: è più difficile avere più sviluppatori che lavorano sul servizio poiché si tratta di un repository di codice monolitico. Inoltre, ciò aumenta il carico cognitivo per gli sviluppatori e rende più difficile creare una copertura di test adeguata per il codice.
+ **Codice più difficile da riutilizzare**: può essere più difficile separare le librerie riutilizzabili dai monoliti, il che rende più difficile il riutilizzo del codice. Man mano che sviluppi e supporti più progetti, ciò può rendere più difficile il supporto del codice e aumentare la velocità del team.
+ **Più difficile da testare**: all'aumentare delle righe di codice, diventa più difficile eseguire test di unità di tutte le possibili combinazioni di input e punti di ingresso nella codebase. In genere è più semplice implementare il test di unità per servizi più piccoli con meno codice.
L'alternativa preferita consiste nel suddividere la funzione Lambda monolitica in singoli microservizi, mappando una singola funzione Lambda a un'unica attività ben definita. In questa semplice applicazione Web con pochi endpoint API, l'architettura risultante basata su microservizi può essere basata sui percorsi API Gateway.
![\[architetture basate sugli eventi (figura 14)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-14.png)
### Schemi ricorsivi che causano funzioni Lambda fuori controllo
AWS i servizi generano eventi che richiamano le funzioni Lambda e le funzioni Lambda possono inviare messaggi ai servizi. AWS In genere, il servizio o la risorsa che richiama una funzione Lambda deve essere diverso dal servizio o dalla risorsa a cui la funzione invia l'output. La mancata gestione di questa situazione può comportare cicli infiniti.
Ad esempio, una funzione Lambda scrive un oggetto su un oggetto Amazon S3, che a sua volta richiama la stessa funzione Lambda tramite un evento put. L'invocazione fa sì che un secondo oggetto venga scritto nel bucket, che richiama la stessa funzione Lambda:
![\[architetture basate sugli eventi (figura 15)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-15.png)
Sebbene il potenziale dei cicli infiniti esista nella maggior parte dei linguaggi di programmazione, questo anti-modello ha il potenziale di consumare più risorse nelle applicazioni serverless. Sia Lambda che Amazon S3 scalano automaticamente in base al traffico, quindi il loop può far sì che Lambda si scali per consumare tutta la concorrenza disponibile e Amazon S3 continuerà a scrivere oggetti e generare più eventi per Lambda.
Questo esempio utilizza S3 ma il rischio di cicli ricorsivi esiste anche in Amazon SNS, Amazon SQS, DynamoDB e altri servizi. È possibile utilizzare il [rilevamento ricorsivo del loop](invocation-recursion.md) per trovare ed evitare questo anti-modello.
### Funzioni Lambda che richiamano funzioni Lambda
Le funzioni consentono l'incapsulamento e il riutilizzo del codice. La maggior parte dei linguaggi di programmazione supporta il concetto di codice che richiama in modo sincrono le funzioni all'interno di una codebase. In questo caso, il chiamante attende che la funzione restituisca una risposta.
**Nota**
Sebbene le funzioni Lambda che richiamano direttamente altre funzioni Lambda siano generalmente un anti-pattern a causa di problemi di costi e complessità, ciò non si applica alle [funzioni durevoli](durable-functions.md), che sono specificamente progettate per orchestrare flussi di lavoro in più fasi richiamando altre funzioni.
Quando ciò accade su un server tradizionale o su un'istanza virtuale, lo scheduler del sistema operativo passa ad altre attività disponibili. Il fatto che la CPU funzioni allo 0% o al 100% non influisce sul costo complessivo dell'applicazione, poiché si paga il costo fisso di proprietà e gestione di un server.
Questo modello spesso non si adatta bene allo sviluppo serverless. Ad esempio, considera una semplice applicazione di e-commerce composta da tre funzioni Lambda che elaborano un ordine:
![\[architetture basate sugli eventi (figura 16)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-16.png)
In questo caso, la funzione *Crea ordine* richiama la funzione *Elabora pagamento*, che a sua volta richiama la funzione *Crea fattura*. Sebbene questo flusso sincrono possa funzionare all'interno di una singola applicazione su un server, introduce diversi problemi evitabili in un'architettura serverless distribuita:
+ **Costo**: con Lambda, paghi per la durata di una invocazione. In questo esempio, mentre le funzioni *Crea fattura* sono in esecuzione, anche altre due funzioni sono in esecuzione in stato di attesa, mostrate in rosso nel diagramma.
+ **Gestione degli errori**: nelle chiamate nidificate, la gestione degli errori può diventare molto più complessa. *Ad esempio, un errore nella *creazione della fattura* potrebbe richiedere la funzione Elabora *pagamento per stornare l'addebito oppure potrebbe invece riprovare il processo* di creazione della fattura.*
+ **Accoppiamento stretto**: l'elaborazione di un pagamento richiede in genere più tempo rispetto alla creazione di una fattura. In questo modello, la disponibilità dell'intero flusso di lavoro è limitata dalla funzione più lenta.
+ **Scalabilità**: la [simultaneità](lambda-concurrency.md) di tutte e tre le funzioni deve essere uguale. In un sistema affollato, ciò utilizza più simultaneità di quanto sarebbe altrimenti necessario.
Nelle applicazioni serverless, esistono due approcci comuni per evitare questo modello. Innanzitutto, usa una coda Amazon SQS tra le funzioni Lambda. Se un processo a valle è più lento di un processo a monte, la coda mantiene i messaggi in modo duraturo e disaccoppia le due funzioni. In questo esempio, la funzione *Create order* pubblicherebbe un messaggio in una coda Amazon SQS e la funzione di *pagamento Process* consumerebbe i messaggi dalla coda.
Il secondo approccio consiste nell'utilizzare AWS Step Functions. Per processi complessi con diversi tipi di logica di errore e nuovo tentativo, Step Functions può aiutare a ridurre la quantità di codice personalizzato necessario per orchestrare il flusso di lavoro. Di conseguenza, Step Functions orchestra il lavoro e gestisce in modo efficace errori e nuovi tentativi, mentre le funzioni Lambda contengono solo la logica aziendale.
### Attesa sincrona all'interno di una singola funzione Lambda
Assicurati che le attività potenzialmente concorrenti non siano pianificate in modo sincrono all'interno di una singola funzione Lambda. Ad esempio, una funzione Lambda potrebbe scrivere su un bucket S3 e quindi scrivere su una tabella DynamoDB:
![\[architetture basate sugli eventi (figura 17)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-17.png)
In questa progettazione, i tempi di attesa sono composti perché le attività sono sequenziali. Nei casi in cui la seconda attività dipende dal completamento della prima, puoi ridurre il tempo di attesa totale e il costo di esecuzione utilizzando due funzioni Lambda distinte:
![\[architetture basate sugli eventi (figura 19)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-19.png)
In questo design, la prima funzione Lambda risponde immediatamente dopo aver inserito l'oggetto nel bucket Amazon S3. Il servizio S3 richiama la seconda funzione Lambda, che quindi scrive i dati nella tabella DynamoDB. Questo approccio riduce al minimo il tempo di attesa totale nelle esecuzioni delle funzioni Lambda.
# Progettazione di applicazioni Lambda
Un'applicazione basata sugli eventi ben progettata utilizza una combinazione di AWS servizi e codice personalizzato per elaborare e gestire richieste e dati. Questo capitolo si concentra su argomenti specifici di Lambda nella progettazione di applicazioni. Ci sono numerose considerazioni importanti per gli architetti serverless quando progettano applicazioni per sistemi di produzione affollati.
Molte delle best practice che si applicano allo sviluppo di software e ai sistemi distribuiti si applicano anche allo sviluppo di applicazioni serverless. L'obiettivo generale è sviluppare carichi di lavoro che siano:
+ **Affidabili**: offrendo agli utenti finali un elevato livello di disponibilità, i servizi serverless AWS sono affidabili perché progettati anche per evitare guasti.
+ **Durevoli**: offrendo opzioni di archiviazione che soddisfano le esigenze di durabilità del carico di lavoro.
+ **Sicuri**: seguendo le best practice e utilizzando gli strumenti forniti per proteggere l'accesso ai carichi di lavoro e limitare il raggio di esplosione.
+ **Performanti**: utilizzando le risorse di elaborazione in modo efficiente e soddisfando le esigenze di prestazioni degli utenti finali.
+ **Efficienti in termini di costi**: progettando architetture che evitino costi inutili, scalabili senza spese eccessive e che possano essere disattivate senza costi generali significativi.
I seguenti principi di progettazione possono aiutarti a creare carichi di lavoro che soddisfino questi obiettivi. Non tutti i principi possono essere applicati a tutte le architetture, ma dovrebbero guidarti nelle decisioni generali sull'architettura.
**Topics**
+ [
## Utilizzare i servizi anziché il codice personalizzato
](#services-custom-code)
+ [
## Informazioni sui livelli di astrazione Lambda
](#level-abstraction)
+ [
## Implementazione stateless nelle funzioni
](#statelessness-functions)
+ [
## Riduzione dell'associazione
](#minimize-coupling)
+ [
## Creazione di dati on demand anziché in batch
](#on-demand-batches)
+ [
## Scegli un'opzione di orchestrazione per flussi di lavoro complessi
](#orchestration)
+ [
## Implementa l'idempotenza
](#retries-failures)
+ [
## Utilizza AWS più account per la gestione delle quote
](#multiple-accounts)
## Utilizzare i servizi anziché il codice personalizzato
Le applicazioni serverless di solito comprendono diversi AWS servizi, integrati con codice personalizzato eseguito nelle funzioni Lambda. Sebbene Lambda possa essere integrato con la maggior parte dei AWS servizi, i servizi più comunemente utilizzati nelle applicazioni serverless sono:
| Categoria | AWS servizio |
| --- | --- |
| Calcolo | AWS Lambda |
| Archiviazione di dati | Simple Storage Service (Amazon S3) Amazon DynamoDB Amazon RDS |
| "Hello, World\$1" | Gateway Amazon API |
| Integrazione delle applicazioni | Amazon EventBridge Amazon SNS Amazon SQS |
| Orchestrazione | Funzioni durevoli Lambda AWS Step Functions |
| Streaming di dati e analisi | Amazon Data Firehose |
**Nota**
Molti servizi serverless forniscono replica e supporto per più regioni, tra cui DynamoDB e Amazon S3. Le funzioni Lambda possono essere implementate in più regioni come parte di una pipeline di implementazione e API Gateway può essere configurato per supportare questa configurazione. Guarda questo [esempio di architettura](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/serverless-architecture-for-global-applications-ra.pdf?did=wp_card&trk=wp_card) che mostra come raggiungere questo obiettivo.
Esistono molti modelli comuni e consolidati nelle architetture distribuite che è possibile creare autonomamente o implementare utilizzando i servizi. AWS Per la maggior parte dei clienti, investire tempo per sviluppare questi modelli partendo da zero ha poco valore commerciale. Quando l'applicazione richiede uno di questi modelli, utilizzate il servizio corrispondente: AWS
| Pattern | AWS servizio |
| --- | --- |
| Queue | Amazon SQS |
| Router di eventi | Amazon EventBridge |
| Pubblicazione/sottoscrizione (fan-out) | Amazon SNS |
| Orchestrazione | Funzioni durevoli Lambda AWS Step Functions |
| "Hello, World\$1" | Gateway Amazon API |
| Flussi di eventi | Amazon Kinesis |
Questi servizi sono progettati per integrarsi con Lambda e puoi utilizzare l'infrastructure as code (IaC) per creare ed eliminare risorse nei servizi. Puoi utilizzare uno qualsiasi di questi servizi tramite l'[SDK AWS](https://aws.amazon.com/tools/) senza dover installare applicazioni o configurare server. Diventare esperti nell'uso di questi servizi tramite codice nelle funzioni Lambda è un passo importante per la produzione di applicazioni serverless ben progettate.
## Informazioni sui livelli di astrazione Lambda
Il servizio Lambda limita l'accesso ai sistemi operativi, agli hypervisor e all'hardware sottostanti che eseguono le funzioni Lambda. Il servizio migliora e modifica continuamente l'infrastruttura per aggiungere funzionalità, ridurre i costi e rendere il servizio più performante. Il codice non deve presupporre alcuna conoscenza dell'architettura di Lambda né presupporre alcuna affinità hardware.
Allo stesso modo, le integrazioni di Lambda con altri servizi sono gestite da AWS, con solo un numero limitato di opzioni di configurazione a tua disposizione. Ad esempio, quando API Gateway e Lambda interagiscono, non sussiste il concetto di bilanciamento del carico poiché è interamente gestito dai servizi. Inoltre, non hai alcun controllo diretto sulle [zone di disponibilità](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) utilizzate dai servizi per invocare le funzioni in qualsiasi momento, o su come Lambda determina quando aumentare o ridurre verticalmente il numero di ambienti di esecuzone.
Questa astrazione ti aiuta a concentrarti sugli aspetti di integrazione dell'applicazione, sul flusso di dati e sulla logica aziendale in cui il carico di lavoro fornisce valore agli utenti finali. Consentire ai servizi di gestire i meccanismi sottostanti consente di sviluppare applicazioni più rapidamente con meno codice personalizzato da gestire.
## Implementazione stateless nelle funzioni
Per le funzioni Lambda standard, è necessario presupporre che l'ambiente esista solo per una singola chiamata. La funzione dovrebbe inizializzare qualsiasi stato richiesto al primo avvio. Ad esempio, la funzione potrebbe richiedere il recupero di dati da una tabella DynamoDB. Deve eseguire eventuali modifiche permanenti ai dati in un archivio durevole come Amazon S3, DynamoDB o Amazon SQS prima dell’uscita. Non dovrebbe basarsi su strutture di dati o file temporanei esistenti o su qualsiasi stato interno che verrebbe gestito da più invocazioni.
Quando si utilizza Durable Functions, lo stato viene automaticamente preservato tra le chiamate, eliminando la necessità di mantenere manualmente lo stato sullo storage esterno. Tuttavia, è comunque necessario seguire i principi stateless per tutti i dati non gestiti in modo esplicito tramite. DurableContext
Per inizializzare le connessioni e le librerie del database o lo stato di caricamento, è possibile sfruttare l'[inizializzazione statica](lambda-runtime-environment.md#static-initialization). Poiché gli ambienti di esecuzione vengono riutilizzati ove possibile per migliorare le prestazioni, è possibile ammortizzare il tempo impiegato per inizializzare queste risorse su più invocazioni. Tuttavia, non è necessario archiviare alcuna variabile o dato utilizzato nella funzione all'interno di questo ambito globale.
## Riduzione dell'associazione
La maggior parte delle architetture dovrebbe preferire molte funzioni più brevi rispetto a un numero inferiore di funzioni più grandi. Lo scopo di ogni funzione dovrebbe essere quello di gestire l'evento trasmesso alla funzione, senza alcuna conoscenza o aspettativa del flusso di lavoro complessivo o del volume delle transazioni. Ciò rende la funzione indipendente dall'origine eventi con un abbinamento minimo ad altri servizi.
Tutte le costanti di ambito globale che cambiano di rado devono essere implementate come variabili di ambiente per consentire aggiornamenti senza implementazioni. Eventuali informazioni segrete o sensibili devono essere archiviate in [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) o [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) e caricate dalla funzione. Poiché queste risorse sono specifiche dell'account, puoi creare pipeline di compilazione su più account. Le pipeline caricano i segreti appropriati per ambiente, senza esporli agli sviluppatori o richiedere modifiche al codice.
## Creazione di dati on demand anziché in batch
Molti sistemi tradizionali sono progettati per funzionare periodicamente ed elaborare batch di transazioni accumulati nel tempo. Ad esempio, un'applicazione bancaria può essere eseguita ogni ora per elaborare le transazioni dei bancomat in log centrali. Nelle applicazioni basate su Lambda, l'elaborazione personalizzata deve essere attivata da ogni evento, consentendo al servizio di aumentare la simultaneità secondo necessità, per fornire un'elaborazione delle transazioni quasi in tempo reale.
Sebbene le funzioni Lambda standard siano limitate a 15 minuti di esecuzione, Durable Functions può funzionare fino a un anno, il che le rende adatte a esigenze di elaborazione più lunghe. Tuttavia, dovresti comunque preferire l'elaborazione basata sugli eventi rispetto all'elaborazione in batch, quando possibile.
Sebbene sia possibile eseguire attività [cron](https://en.wikipedia.org/wiki/Cron) in applicazioni serverless [utilizzando espressioni pianificate](https://docs.aws.amazon.com/eventbridge/latest/userguide/scheduled-events.html) per le regole in Amazon EventBridge, queste dovrebbero essere utilizzate con parsimonia o come ultima risorsa. In qualsiasi attività pianificata che elabora un batch, esiste la possibilità che il volume delle transazioni cresca oltre quanto può essere elaborato entro il limite di durata Lambda di 15 minuti. Se le limitazioni dei sistemi esterni ti obbligano a utilizzare uno scheduler, in genere dovresti programmare per il periodo di tempo ricorrente più breve e ragionevole.
Ad esempio, non è consigliabile utilizzare un processo batch che attiva una funzione Lambda per recuperare un elenco di nuovi oggetti Amazon S3. Questo perché il servizio può ricevere più nuovi oggetti tra un batch e l'altro di quanti ne possano essere elaborati in una funzione Lambda di 15 minuti.
![\[architetture basate sugli eventi (figura 10)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-10.png)
Invece, Amazon S3 deve invocare la funzione Lambda ogni volta che un nuovo oggetto viene inserito nel bucket. Questo approccio è significativamente più scalabile e funziona quasi in tempo reale.
![\[architetture basate sugli eventi (figura 11)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/event-driven-architectures-figure-11.png)
## Scegli un'opzione di orchestrazione per flussi di lavoro complessi
I flussi di lavoro che coinvolgono la logica di ramificazione, diversi tipi di modelli di errore e la logica dei tentativi in genere utilizzano un orchestratore per tenere traccia dello stato dell'esecuzione complessiva. Non creare orchestrazione ad hoc nelle funzioni Lambda standard. Ciò si traduce in un accoppiamento stretto, un codice di routing complesso e nessun ripristino automatico dello stato.
Utilizza invece una di queste opzioni di orchestrazione appositamente progettate:
+ **[Funzioni durevoli Lambda](durable-functions.md):** orchestrazione incentrata sulle applicazioni utilizzando linguaggi di programmazione standard con checkpoint automatico, riprova integrata e ripristino dell'esecuzione. Ideale per gli sviluppatori che preferiscono mantenere la logica del flusso di lavoro nel codice insieme alla logica aziendale in Lambda.
+ **[AWS Step Functions](with-step-functions.md):** orchestrazione visiva del flusso di lavoro con integrazioni native per oltre 220 servizi. AWS Ideale per il coordinamento multiservizio, l'infrastruttura senza manutenzione e la progettazione di flussi di lavoro visivi.
Per indicazioni sulla scelta tra queste opzioni, consulta [Durable functions o Step Functions](durable-step-functions.md).
Con [ Step Functions](https://aws.amazon.com/step-functions/), si utilizzano macchine a stati per gestire l'orchestrazione. Questo estrae la gestione degli errori, il routing e la logica di ramificazione dal codice, sostituendola con macchine a stati dichiarate utilizzando JSON. Oltre a rendere i flussi di lavoro più robusti e osservabili, puoi anche aggiungere il controllo delle versioni ai flussi di lavoro e rendere la macchina a stati una risorsa codificata da aggiungere a un archivio di codice.
È normale che i flussi di lavoro più semplici nelle funzioni Lambda diventino più complessi nel tempo. Quando si utilizza un'applicazione serverless di produzione, è importante identificare quando ciò accade, in modo da poter migrare questa logica verso una macchina a stati o una funzione durevole.
## Implementa l'idempotenza
AWS i servizi serverless, tra cui Lambda, sono tolleranti ai guasti e progettati per gestire i guasti. Ad esemoio, se un servizio richiama una funzione Lambda e si verifica un'interruzione del servizio, Lambda invoca la funzione in una zona di disponibilità diversa. Se la funzione emette un errore, Lambda ritenta l’invocazione.
Poiché lo stesso evento può essere ricevuto più di una volta, le funzioni devono essere progettate in modo da essere [idempotenti](https://en.wikipedia.org/wiki/Idempotence). Ciò significa che ricevere lo stesso evento più volte non modifica il risultato dopo la prima ricezione dell'evento.
Puoi implementare l'idempotenza nelle funzioni Lambda utilizzando una tabella DynamoDB per tenere traccia degli identificatori elaborati di recente per determinare se la transazione è già stata gestita in precedenza. La tabella DynamoDB di solito implementa un valore [Time To Live (TTL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) per gli elementi con scadenza per limitare lo spazio di archiviazione utilizzato.
## Utilizza AWS più account per la gestione delle quote
Molte [quote di servizio](gettingstarted-limits.md) AWS sono impostate a livello di account. Ciò significa che man mano che aggiungi più carichi di lavoro, puoi esaurire rapidamente i tuoi limiti.
Un modo efficace per risolvere questo problema consiste nell'utilizzare più AWS account, dedicando ogni carico di lavoro al proprio account. Ciò impedisce che le quote vengano condivise con altri carichi di lavoro o risorse non di produzione.
In aggiunta, utilizzando [Organizzazioni AWS](https://aws.amazon.com/organizations/), puoi gestire centralmente la fatturazione, la conformità e la sicurezza di questi account. È possibile collegare policy a gruppi di account per evitare script personalizzati e processi manuali.
Un approccio comune consiste nel fornire a ogni sviluppatore un AWS account e quindi utilizzare account separati per la fase di distribuzione beta e la produzione:
![\[progettazione dell'applicazione (figura 3)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/application-design-figure-3.png)
In questo modello, ogni sviluppatore ha i propri limiti per l'account, quindi il loro utilizzo non ha alcun impatto sull'ambiente di produzione. Questo approccio consente inoltre agli sviluppatori di testare le funzioni Lambda localmente sulle proprie macchine di sviluppo con risorse cloud attive nei propri account individuali.