Introduzione

Principiante | 10 minuti

Serverless - Analisi approfondite presenta i concetti fondamentali, le architetture di riferimento, le best practice e le attività pratiche per aiutarti a iniziare a costruire applicazioni serverless. Questo è il posto ideale per iniziare se sei un principiante in fatto di serverless. Per i creatori serverless esperti sono disponibili risorse e collegamenti ad argomenti più avanzati.

Cosa significa serverless?

Serverless consente di creare ed eseguire applicazioni e servizi senza dover gestire alcun server. Elimina le attività di gestione delle infrastrutture come il provisioning del server o del cluster, l'applicazione di patch, la manutenzione del sistema operativo e il provisioning della capacità. Possono adattarsi a quasi ogni tipo di applicazione o servizio di back-end; tutte le operazioni necessarie per l'esecuzione e la scalabilità dell'applicazione saranno gestite in automatico.

Le applicazioni serverless sono basate su eventi e in accoppiamento debole tramite API indipendenti dalla tecnologia o messaggistica. Il codice basato su eventi viene eseguito in risposta a un evento, come un cambiamento di stato o una richiesta di endpoint. Le architetture basate su eventi disaccoppiano il codice dallo stato. L'integrazione tra componenti in accoppiamento debole solitamente avviene in modo asincrono tramite messaggistica.

AWS Lambda è un servizio di elaborazione serverless adatto ad architetture basate su eventi. Le funzioni Lambda sono attivate da eventi tramite origini di eventi integrate come Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) e Amazon Kinesis che possono essere usate per creare integrazioni asincrone. Le funzioni Lambda consumano e producono eventi che altri servizi possono consumare successivamente.

I modelli architetturali serverless usano Lambda con altri servizi gestiti che sono anch'essi serverless. Oltre ai servizi di messaggistica e streaming, le architetture serverless usano servizi gestiti come Amazon API Gateway per la gestione dell'API, Amazon DynamoDB per i datastore e AWS Step Functions per l'orchestrazione. La piattaforma serverless include inoltre una serie di strumenti per sviluppatori tra cui il Serverless Application Model, o SAM, che aiuta a semplificare la distribuzione e il test delle funzioni Lambda e delle applicazioni serverless.

Perché utilizzare il serverless?

Nessuna gestione di server: non è più necessario allocare o gestire server. Non è necessario installare, gestire e amministrare alcun software o runtime.

Scalabilità e flessibilità: le risorse dell'applicazione saranno ricalibrate automaticamente, oppure la capacità sarà ottimizzata in base alle unità necessarie (ad esempio di memoria o di throughput), piuttosto che a unità di singoli server.

Prezzi in base al valore: paga per throughput coerente o durata di esecuzione piuttosto che per unità di server.

Disponibilità elevata automatizzata: il serverless fornisce elevata disponibilità e funzionalità di tolleranza ai guasti. Non è quindi più necessario progettare l'integrazione di queste caratteristiche, perché sono garantite di default dai servizi che eseguono l'applicazione.

Servizi serverless fondamentali

Le applicazioni serverless vengono generalmente create usando servizi completamente gestiti come blocchi predefiniti attraverso livelli di elaborazione, dati, messaggistica e integrazione, streaming e gestione degli utenti e identità. Servizi come AWS Lambda, API Gateway, SQS, SNS, EventBridge o Step Functions sono il nucleo della maggior parte delle applicazioni, supportati come servizi come DynamoDB, S3 o Kinesis.

Categoria
Servizio
Descrizione
Calcolo AWS Lambda AWS Lambda consente di eseguire applicazioni serverless stateless su una piattaforma gestita
che supporta architetture di microservizi, distribuzione e gestione dell'esecuzione
al livello di funzione.
Proxy API API Gateway Amazon API Gateway è un servizio completamente gestito che consente agli sviluppatori di
creare, pubblicare, mantenere, monitorare e proteggere facilmente le API su qualsiasi scala. Offre una
piattaforma completa per la gestione delle API. API Gateway consente di elaborare
centinaia di migliaia di chiamate API simultanee e si occupa della gestione del traffico,
del controllo delle autorizzazioni e degli accessi, del monitoraggio e della gestione della versione dell'API.
Messaggistica e integrazione SNS Amazon SNS è un servizio di messaggistica pub/sub completamente gestito che facilita il
disaccoppiamento e la ricalibrazione dei microservizi, dei sistemi distribuiti e delle applicazioni serverless.
SQS Amazon SQS è un servizio di accodamento dei messaggi completamente gestito che facilita il
disaccoppiamento e la ricalibrazione dei microservizi, dei sistemi distribuiti e delle applicazioni serverless.
EventBridge Amazon EventBridge è un bus di eventi serverless che facilita la connessione tra applicazioni
usando i dati dalle tue applicazioni, le applicazioni Software-as-a-Service (SaaS)
integrate e i servizi AWS.
Orchestrazione Step Functions
AWS Step Functions facilita il coordinamento dei componenti di applicazioni distribuite
e dei microservizi usando flussi di lavoro visivi.

Creiamo!

Di seguito sono presentate alcune risorse per aiutarti a conoscere i nostri servizi serverless fondamentali.

Esecuzione di un "Hello, World!" serverless

Crea una funzione Lambda Hello World usando la console AWS Lambda e impara le nozioni di base su come eseguire il codice senza dover effettuare il provisioning o gestire alcun server.

Inizia il tutorial >>

Creare miniature da immagini caricate

Crea una funzione Lambda richiamata da Amazon S3 ogni volta che viene caricato un file immagine in un bucket S3 e crea automaticamente una miniatura di quell'immagine.

Inizia il tutorial >>

Creazione della tua prima applicazione con AWS Lambda
Creazione di un microservizio semplice

Usa la console Lambda per creare una funzione Lambda e un endpoint Amazon API Gateway per attivare tale funzione.

Inizia il tutorial >>

Creazione di un flusso di lavoro serverless

Scopri come usare AWS Step Functions per progettare ed eseguire un flusso di lavoro serverless che coordini più funzioni AWS Lambda.

Inizia il tutorial >>

Principi fondamentali

Intermedio | 20 minuti

In questa sezione riceverai informazioni sulla progettazione basata su eventi, il principio fondamentale dietro le applicazioni serverless scalabili.

Progettazione basata su eventi

Un'architettura basata su eventi usa gli eventi per attivarsi e comunicare fra servizi disaccoppiati. Un evento è un cambiamento di stato, o un aggiornamento, come un articolo che viene messo nel carrello su un sito Web di e-commerce. Gli eventi possono comunicare lo stato (ad esempio, l'articolo acquistato, il suo prezzo e un indirizzo di consegna) o possono essere identificatori (ad esempio, un avviso di spedizione dell'ordine).

Le architetture basate su eventi hanno tre componenti: produttori dell'evento, router dell'evento e consumatori dell'evento. Un produttore pubblica un evento sul router, che filtra e inoltra gli eventi ai consumatori. I servizi produttore e consumatore vengono disaccoppiati, il che consente di scalarli, aggiornarli e distribuirli indipendentemente.

Per comprendere perché è auspicabile un'architettura basata su eventi, diamo un'occhiata a una chiamata API sincrona.

Serverless deep dive synchronous api call

I clienti sfruttano i tuoi microservizi eseguendo chiamate API HTTP. Amazon API Gateway ospita richieste e risposte HTTP RESTful ai clienti. AWS Lambda contiene la logica di business per elaborare le chiamate API in entrata e sfruttare DynamoDB come storage persistente.

Se richiamato in modo sincrono, API Gateway si aspetta una risposta immediata e ha un timeout di 30 secondi. Con origini di eventi sincrone, se la risposta da Lambda richiede oltre 30 secondi, l'utente avrà la responsabilità di scrivere qualsiasi nuovo tentativo e codice di gestione dell'errore. Per questo motivo, qualsiasi errore o problema di dimensionamento che si verifica con qualsiasi componente a valle rispetto al cliente, come le unità di capacità in lettura/scrittura in DynamoDB, verrà inoltrato di nuovo al cliente per la gestione del codice front-end. Usando modelli asincroni e disaccoppiando questi componenti è possibile creare un sistema più robusto e altamente scalabile.

Inviare notifiche di eventi in fan-out

Scopri come implementare uno scenario di messaggistica in fan-out in cui i messaggi vengono inviati tramite push agli iscritti al servizio, eliminando la necessità di verificare periodicamente o eseguire il polling degli aggiornamenti e attivando l'elaborazione asincrona in parallelo dei messaggi da parte degli iscritti al servizio.

Inizia il tutorial >>

Integrazione di Amazon EventBridge nelle tue applicazioni serverless

Scopri come creare un produttore e un consumatore dell'evento in AWS Lambda e creare una regola per eseguire il routing di eventi.

Inizia il tutorial >>

Passaggio alle architetture basate su eventi
Trigger e origini di eventi

Le funzioni Lambda sono attivate da eventi. Eseguono quindi il codice in risposta al trigger e possono anche generare i loro eventi. Sono disponibili molte opzioni per attivare una funzione Lambda e l'utente ha ampia flessibilità nel creare origini di eventi personalizzate adatte alle specifiche esigenze.

I principali tipi di origini di eventi sono:

  • I datastore, come Amazon S3, Amazon DynamoDB o Amazon Kinesis possono attivare funzioni Lambda. Se archiviano i dati dei quali si desidera monitorare le modifiche, possono essere potenzialmente usati come origine di eventi.
  • Gli endpoint che generano eventi possono richiamare Lambda. Ad esempio, quando si chiede ad Alexa di fare qualcosa, questa genera un evento che attiva una funzione Lambda.
  • Anche i servizi di messaggistica, come Amazon SQS o Amazon SNS possono essere origini di eventi. Ad esempio, quando si invia qualcosa a un argomento SNS, questo può attivare una funzione Lambda.
  • Quando certe azioni si verificano all'interno di un repository, come quando si affida un codice al repository AWS CodeCommit, questo può attivare una funzione Lambda, ad esempio per avviare il processo di costruzione di CI/CD.
Serverless deep dive event source trigger
Richiamare funzioni AWS Lambda

Scopri tutte le informazioni su come richiamare funzioni AWS Lambda con la nostra guida per gli sviluppatori.

Consulta la guida per gli sviluppatori >>

Scelta di eventi, code, argomenti e flussi nella tua applicazione serverless
Architetture di riferimento

In questa sezione troverai una suite di architetture di riferimento che trattano i casi d'uso delle applicazioni serverless più comuni.

  • Microservizi RESTful

    Le tecnologie serverless sono create su infrastrutture a disponibilità elevata e con tolleranza ai guasti, consentendo all'utente di creare servizi affidabili per i carichi di lavoro mission critical. I servizi serverless fondamentali di AWS sono strettamente integrati con tantissimi altri servizi e beneficiano di un ricco ecosistema di strumenti AWS e dei partner di terze parti. Questo sistema consente di ottimizzare il processo di costruzione, automatizzare le attività, organizzare servizi e dipendenze, e monitorare i microservizi. Con i servizi serverless di AWS, i prezzi sono calcolati solo in base all'uso effettivo. Questo consente di aumentare l'uso nella tua azienda e di mantenere i costi bassi in caso di scarso utilizzo. Tutte queste caratteristiche rendono le tecnologie serverless lo strumento ideale per creare microservizi resilienti.

    Esempio di architettura di microservizi RESTful

    Serverless deep dive restful microservice architecture

    I clienti sfruttano i tuoi microservizi eseguendo chiamate API HTTP. Idealmente, i consumatori devono avere un contratto di servizio vincolato alla tua API per soddisfare in modo coerente le aspettative relative ai livelli di servizio e al controllo delle modifiche.

    Amazon API Gateway ospita richieste e risposte HTTP RESTful ai clienti. In questo scenario, API Gateway fornisce autorizzazioni integrate, throttling, sicurezza, tolleranza ai guasti, mappatura di richieste/risposte e ottimizzazioni delle prestazioni.

    AWS Lambda contiene la logica di business per elaborare le chiamate API in entrata e sfruttare DynamoDB come storage persistente.

    Amazon DynamoDB memorizza in modo persistente i dati dei microservizi e ricalibra in base alla domanda. Siccome i microservizi sono spesso progettati per eseguire un'operazione correttamente, viene regolarmente integrato un datastore NoSQL senza schema.

  • Elaborazione di immagini

    L'elaborazione di immagini è un carico di lavoro comune che può essere basato su eventi e richiede il ridimensionamento verso il basso e verso l'alto in modo dinamico, che è quello per cui le tecnologie serverless sono adatte. Generalmente, le immagini vengono archiviate in Amazon S3, che può attivare funzioni Lambda per l'elaborazione. Dopo l'elaborazione, la funzione Lambda può restituire la versione modificata a un altro bucket S3 o a API Gateway.

    Il diagramma di seguito presenta l'architettura Serverless Image Handler che è possibile distribuire in pochi minuti grazie alla guida all'implementazione della soluzione e al relativo modello AWS CloudFormation.

    Serverless deep dive image handler

    AWS Lambda recupera le immagini dal tuo bucket Amazon Simple Storage Service (Amazon S3) e usa Sharp per restituire una versione modificata dell'immagine ad Amazon API Gateway. La soluzione genera un nome di dominio Amazon CloudFront che consente l'accesso in cache verso l'API del gestore di immagini.

    Inoltre, la soluzione distribuisce un'interfaccia utente demo opzionale dove è possibile interagire direttamente con l'endpoint dell'API del gestore di immagini usando file immagini già esistenti nell'account dell'utente. La UI demo è distribuita in un bucket Amazon S3 per consentire ai clienti di iniziare immediatamente a manipolare immagini con una semplice interfaccia Web. CloudFront viene utilizzato per limitare l'accesso ai contenuti del bucket del sito Web della soluzione.

    Distribuisci la soluzione >>

  • Elaborazione in flussi

    Puoi usare AWS Lambda e Amazon Kinesis per elaborare dati di streaming in tempo reale a scopo di monitoraggio delle attività dell'applicazione, elaborazione degli ordini di transazione, analisi dei dati di clickstream, pulizia dei dati, generazione di parametri, filtraggio di log, indicizzazione, analisi di social media e telemetria e misurazione di dispositivi IoT.

    Esempio di architettura di elaborazione di flussi

    serverless deep dive stream processing

    L'architettura descritta in questo diagramma può essere creata con un modello di AWS CloudFormation. Il modello eseguirà le seguenti operazioni:

    • Crea un flusso Kinesis
    • Crea una tabella DynamoDB chiamata -EventData
    • Crea la funzione Lambda 1 (-DDBEventProcessor) che riceve record da Kinesis e scrive record sulla tabella DynamoDB
    • Crea un ruolo IAM e una policy per consentire alla funzione Lambda di elaborazione di eventi di leggere dal flusso Kinesis e scrivere sulla tabella DynamoDB
    • Crea un utente IAM con il permesso di inserire eventi nel flusso Kinesis insieme alle credenziali che il cliente può usare in un client API
  • Applicazione Web

    Usando l'elaborazione serverless su AWS, l'utente può distribuire tutto il suo stack di applicazioni Web senza gestire server, eseguire il provisioning di capacità o pagare per risorse inattive. Inoltre, non occorre scendere a compromessi in termini di sicurezza, affidabilità o prestazioni. Le applicazioni Web create usando tecnologie serverless offrono elevata disponibilità e possono essere dimensionate a livello globale su richiesta.

    serverless deep dive web application
    1. I consumatori di questa applicazione Web potrebbero essere geograficamente concentrati o distribuiti in tutto il mondo. L'utilizzo di Amazon CloudFront non solo fornisce una migliore esperienza di prestazioni per questi consumatori attraverso il caching e l'instradamento di origine ottimale, ma limita anche le chiamate ridondanti al backend.
    2. Amazon S3 ospita asset statici per applicazioni Web ed è gestito in modo sicuro tramite CloudFront.
    3. Un pool di utenti di Amazon Cognito fornisce funzionalità di gestione degli utenti e provider di identità per la tua applicazione Web.
    4. In molti scenari, poiché i contenuti statici di Amazon S3 vengono scaricati dal consumatore, i contenuti dinamici devono essere inviati o ricevuti dall'applicazione. Ad esempio, quando un utente invia dati tramite un modulo, Amazon API Gateway funge da endpoint sicuro per effettuare queste chiamate e restituire le risposte visualizzate tramite l'applicazione Web.
    5. Una funzione AWS Lambda fornisce operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) su DynamoDB per la tua applicazione Web.
    6. Amazon DynamoDB è in grado di fornire il datastore NoSQL di backend per ricalibrare in modo elastico il traffico della tua applicazione Web.
Distribuzione

Una best practice per le distribuzioni in un'architettura di microservizi consiste nel garantire che una modifica non interrompa il contratto di servizio del consumatore. Se il proprietario dell'API apporta una modifica che interrompe il contratto di servizio e il consumatore non è preparato, possono verificarsi errori.

Per comprendere l'impatto dei cambiamenti di distribuzioni, occorre sapere quali consumatori utilizzano la tua API. Le chiavi API possono essere usate per raccogliere i metadati sull'uso e possono anche essere usate come modulo di contatto se una modifica di rottura viene eseguita su un'API.

Quando i consumatori vogliono attenuare l'impatto delle modifiche di rilievo a un'API, questi possono clonare l'API e instradare i consumatori verso un altro sottodominio (ad esempio, v2.my-service.com) per assicurarsi che i consumatori esistenti non vengano coinvolti. Questo approccio consente agli utenti di distribuire solo le nuove modifiche al nuovo contratto di servizio dell'API, ma richiede dei compromessi. I clienti che adottano questo approccio devono conservare due versioni dell'API e dovranno occuparsi della gestione dell'infrastruttura e degli oneri operativi di provisioning.

Distribuzione
Impatto sul cliente
Rollback Fattori del modello di eventi
Velocità di distribuzione
All-at-once All at once (Tutto contemporaneamente) Ridistribuisci la versione precedente Qualsiasi modello di evento a bassa velocità di simultaneità Immediato
Blu/Verde All at once (Tutto contemporaneamente) con un certo livello di test dell'ambiente di produzione in anticipo Ripristina il traffico nell'ambiente precedente Ideale per modelli di eventi asincroni e sincroni con carichi di lavoro di media simultaneità Da minuti a ore di convalida e immediati per i clienti
Canary/Lineare 1-10% tipico spostamento del traffico iniziale, quindi incrementi per fasi o tutti contemporaneamente Ripristina il 100% del traffico alla distribuzione precedente Ideale per carichi di lavoro con elevata simultaneità Da minuti a ore
  • Distribuzioni all-at-once

    Le distribuzioni all-at-once implicano l'applicazione di modifiche alla configurazione esistente. Un vantaggio di questo stile di distribuzione è che le modifiche del back-end ai datastore, per esempio un database relazionale, richiedono un sforzo minore per riconciliare le transazioni durante il ciclo di modifica. Anche se questo tipo di stile di distribuzione riduce gli sforzi e può essere creato con un impatto ridotto nei modelli a bassa simultaneità, aumenta i rischi relativi al rollback e può causare tempi di inattività. Uno scenario di esempio per utilizzare questo modello di distribuzione sono gli ambienti di sviluppo con un impatto utente minimo.

    Prova una distribuzione all-at-once >>

  • Distribuzioni blu/verde

    Con il modello di distribuzione blu/verde i clienti trasferiscono una sezione di traffico al nuovo ambiente in diretta (verde) mantenendo il vecchio ambiente di produzione (blu) pronto nel caso in cui sia necessario un rollback del sistema. Quando si usa questo modello, è meglio apportare modifiche di piccola entità in modo da poter eseguire i rollback in modo rapido e semplice. Poiché le distribuzioni blu/verdi sono progettate per ridurre i tempi di inattività, molti clienti adottano questo modello per la distribuzione in produzione. API Gateway consente di definire facilmente quale percentuale di traffico viene trasferita al nuovo ambiente verde, rendendo questo modello di distribuzione uno strumento efficace.

    Questo stile di distribuzione è particolarmente adatto per le architetture serverless, che sono sia stateless che disaccoppiate dall'infrastruttura sottostante.

    È necessario disporre degli indicatori corretti per sapere se bisogna effettuare un rollback. Tra le best practice, consigliamo ai clienti di utilizzare parametri ad alta risoluzione di CloudWatch, che possono monitorare intervalli di 1 secondo e acquisire rapidamente i trend in ribasso. È possibile abilitare un rollback rapido con gli allarmi di CloudWatch. I parametri di CloudWatch possono essere acquisiti su API Gateway, Step Functions, Lambda (inclusi i parametri personalizzati) e DynamoDB.

  • Distribuzioni Canary

    Le distribuzioni Canary sono un modo in costante aumento per sfruttare il nuovo rilascio di un software in un ambiente controllato e consentire cicli di distribuzione rapidi. Le distribuzioni Canary prevedono la distribuzione di un piccolo numero di richieste alla nuova modifica per analizzare l'impatto su un piccolo numero di utenti.

    Con le distribuzioni Canary in API Gateway, puoi distribuire una modifica all'endpoint di back-end (per esempio Lambda) mantenendo lo stesso endpoint HTTP di API Gateway per i consumatori. Inoltre, puoi controllare quale percentuale di traffico viene instradata verso una nuova distribuzione e per un passaggio di traffico controllato. Uno scenario pratico per una distribuzione Canary potrebbe essere un nuovo sito Web. Puoi monitorare le percentuali di clic su un piccolo numero di utenti finali prima di trasferire tutto il traffico alla nuova distribuzione.

    Implementazione di distribuzioni Canary di funzioni AWS Lambda con Alias Traffic Shifting

    Scopri come implementare distribuzioni Canary delle funzioni AWS Lambda.

    Leggi il post nel blog >>

    Distribuzione graduale di applicazioni serverless

    AWS SAM offre distribuzioni Lambda graduali per le tue applicazioni serverless.

    Consulta la guida per gli sviluppatori >>

Altre risorse

Tutorial pratici
Accedi all’inventario completo di tutorial sul serverless e ottieni un apprendimento più pratico.
Visualizza i tutorial pratici >>
Blog sul serveless di AWS
Scopri le ultime notizie e gli aggiornamenti sul serverless sul blog sul serverless di AWS.
Leggi i post del blog >>
Analisi approfondite di categoria
Approfondisci le tecnologie specifiche e ottieni il massimo da AWS Cloud.
Visualizza le analisi approfondite di categoria >>