Lambda spiegato come se avessi 5 anni

Serverless.

C’è una parola, nel mondo cloud, che fa sentire idioti più di qualunque altra al primo incontro. Quella parola è “serverless”. Letteralmente: senza server. Il che è impossibile, perché ovviamente i server esistono, il codice gira da qualche parte, l’elettricità la paga qualcuno. Eppure lo chiamiamo serverless. E Lambda è il servizio AWS più rappresentativo di questa categoria.

Risultato: Francesco apre la documentazione di Lambda, legge “compute serverless”, si chiede “ma quindi… non ci sono server? E dove gira il codice? E come pago?” e dopo dieci minuti chiude la tab.

In questo articolo ti spiego Lambda con un’analogia immediata, ti racconto in tre mosse cosa succede davvero quando una Lambda esegue, ti faccio vedere quando è la risposta giusta (e quando è una trappola d’esame), e ti porto al tuo primo deploy in 15 minuti. Senza buzzword.

Lambda non è “niente server”. È server che non gestisci tu.

Prima cosa, sgombro il campo dall’equivoco semantico.

Su Lambda i server esistono. Sono dentro i data center AWS, sono accesi, costano elettricità. La differenza è che non sono tuoi. Non li scegli, non li configuri, non li monitori, non li paghi quando non li usi. AWS tiene grandi “flotte” di server pronti, e quando arriva un evento ti assegna istantaneamente uno slot, ci fa girare il tuo codice, e ti restituisce il risultato.

Pensalo così. Un distributore automatico.

Tu non possiedi il distributore. Non lo accendi, non lo riempi, non paghi la corrente che consuma di notte quando nessuno passa. Lo usi solo quando ti serve. Inserisci una moneta, l’evento, schiacci il pulsante, la richiamata della funzione, ed esce il prodotto, il risultato del codice. Ti viene fatturata quella singola lattina, non il distributore.

Ecco Lambda. È un distributore automatico di codice.

Questo cambia tre cose, profonde:

Non paghi per il tempo morto. Se la tua Lambda viene chiamata 100 volte al giorno per 200 millisecondi ogni volta, paghi 20 secondi al giorno. Punto.
Non gestisci l’infrastruttura. Niente patching dell’OS, niente scaling manuale, niente capacity planning. Se di colpo arrivano 10.000 chiamate al secondo, AWS scala. Se non arriva nessuna chiamata, AWS non addebita.
Non hai stato persistente in memoria. Ogni invocazione è isolata. La Lambda non “ricorda” la chiamata precedente, se ti serve memoria condivisa, la metti su DynamoDB, S3, o ElastiCache.

Lambda non è magia. È un cambio di modello: paghi l’esecuzione, non il server. Il resto, ne discendono tutte le conseguenze.

Evento, codice, risposta: il ciclo in tre mosse

Una Lambda esegue solo se qualcuno la chiama. Quel “qualcuno” si chiama evento. E il ciclo di vita di ogni invocazione è sempre lo stesso.

1. Evento. Qualcosa genera un trigger. Le sorgenti tipiche sono:

una chiamata HTTP attraverso API Gateway (la più comune per back-end web);
l’arrivo di un oggetto in un bucket S3 (es. una foto caricata da un utente);
uno schedule cron tramite EventBridge (es. “esegui ogni mattina alle 6”);
un messaggio in una coda SQS o uno stream di DynamoDB;
una notifica SNS.

Ce ne sono molti altri, quasi ogni servizio AWS può triggerare una Lambda. Quello che conta capire ora è che Lambda non gira da sola: serve sempre qualcuno che la chiami.

2. Codice. AWS prende il tuo codice (Python, Node.js, Java, Go, Ruby, .NET, o un container Docker custom), lo carica su uno dei server della sua flotta, e lo esegue passando l’evento come input. Il codice fa quello che deve fare: trasformare i dati, scrivere su un database, chiamare un’API esterna, restituire una risposta HTTP. Tutto in millisecondi.

3. Risposta. La funzione termina, restituisce un output, e AWS gestisce il “dove finisce”. Se l’evento veniva da API Gateway, l’output torna come response HTTP all’utente. Se veniva da S3, di solito non torna a nessuno (la Lambda ha fatto qualcosa, e basta). Se veniva da una coda SQS, il messaggio viene marcato come processato. La fatturazione si chiude su quei millisecondi e su quella memoria allocata.

Tre cose, due delle quali AWS le fa al posto tuo. La tua responsabilità si riduce al codice, e quello, onestamente, è il punto.

C’è una cosa da sapere sulla performance: la prima invocazione di una Lambda “fredda” richiede di caricare l’ambiente di runtime, e questo aggiunge un ritardo (il famoso cold start) di qualche centinaio di millisecondi. Le invocazioni successive, finché la Lambda è “calda”, partono in millisecondi puliti. Per la maggior parte dei casi d’uso non è un problema. Per applicazioni con latenza critica, esistono soluzioni (Provisioned Concurrency, SnapStart per Java), ma non ci pensare al primo giro.

Quando Lambda è la risposta (e quando è una trappola)

Lambda è meraviglioso per alcuni casi d’uso, e profondamente sbagliato per altri. Capire la differenza è metà della risposta a qualunque domanda d’esame che inizia con “L’azienda vuole…”.

Lambda è la scelta giusta quando:

Hai un back-end HTTP a chiamate brevi. Una API REST in cui ogni richiesta dura pochi secondi al massimo. API Gateway davanti a Lambda è il pattern standard.
Vuoi processare eventi in modo asincrono. Un utente carica una foto su S3, una Lambda la ridimensiona automaticamente. Un nuovo record arriva su DynamoDB, una Lambda manda una notifica via SNS. Pattern event-driven puro.
Hai task pianificati leggeri. EventBridge schedula un cron, la Lambda gira ogni mattina alle 6, esegue un report e finisce. Cinque secondi al giorno, costo prossimo allo zero.
Il traffico è imprevedibile o intermittente. Lambda scala da 0 a migliaia di esecuzioni simultanee senza che tu faccia nulla. Pagamento al consumo significa che se nessuno usa l’app per due giorni, non paghi nulla.

Lambda è la scelta sbagliata quando:

Il workload è continuo e con traffico alto stabile. A volumi sostenuti, EC2 con Auto Scaling o Fargate costano meno. Lambda diventa caro quando giri 24/7 a piena potenza.
L’esecuzione dura più di 15 minuti. Il timeout massimo di una Lambda è 15 minuti. Per training di modelli ML, elaborazioni batch lunghe o lavori HPC, non è il servizio giusto. Pensa a ECS, Fargate, AWS Batch o EC2.
Hai bisogno di stato persistente in memoria locale. Una Lambda non “ricorda” la chiamata precedente. Una WebSocket server con sessioni utente attive non è un pattern Lambda, anche se esistono workaround con API Gateway WebSocket + DynamoDB, sono complicati.
Hai dipendenze di sistema operativo molto specifiche o binari pesanti. Lambda supporta container Docker da qualche anno, e questo ha alzato il tetto delle dipendenze gestibili. Ma se hai vincoli stretti su una versione di Linux specifica o su un binario di 8 GB, è quasi sempre più semplice un container ECS.

Questa è una delle 5-6 distinzioni che il SAA ti chiede in modo ricorrente. Trappola d’esame classica: una domanda dice “workload che gira continuamente, traffico costante, alto throughput” e Lambda è una delle opzioni. Sembra plausibile. Non lo è. La risposta giusta è quasi sempre EC2 con Auto Scaling o Fargate.

L’argomento merita un articolo a sé, ed esiste, nel prossimo del piano editoriale: “EC2, Lambda o Fargate? La scelta che sbagliano tutti”.

Il primo Lambda, passo passo

Quindici minuti, dall’account vuoto al primo deploy. Ecco l’ordine.

Apri la console AWS, cerca “Lambda” e clicca Create function. Scegli Author from scratch. Dai un nome alla funzione (es. hello-world-1), seleziona un runtime, Python 3.x è il più semplice per iniziare. AWS ti propone di creare automaticamente un execution role IAM minimo: accetta. (Se hai capito IAM, sai che è un role per la Lambda, la dovevi creare con quello.)

Si apre l’editor con un codice Python di default. È letteralmente:

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": "Hello from Lambda!"
    }

Tre cose da osservare: il nome della funzione handler (lambda_handler) è il punto d’ingresso che AWS chiama, event contiene i dati passati dal trigger, context contiene metadata sull’esecuzione (ID dell’invocazione, memoria residua, tempo rimanente).

Clicca Test in alto a destra. AWS ti chiede di configurare un evento di test, accetta il template di default e dai un nome (es. test1). Clicca Test di nuovo. Vedi l’output. Funziona. Sei vivo.

Tocca Monitor → View CloudWatch logs. Lì trovi ogni print() della Lambda e ogni stack trace di errore. È il tuo primo posto di indagine quando qualcosa non torna.

Per il bonus, aggiungi un trigger. Sezione Add trigger → seleziona API Gateway → crea una nuova API REST con autenticazione Open (è una demo, non un’app vera). AWS ti genera un URL pubblico. Aprilo nel browser. La tua Lambda risponde su HTTP. Hai appena messo in produzione un back-end serverless.

Tempo totale, la prima volta: 15 minuti. La seconda: 3. È questa velocità di iterazione, più ancora del prezzo, il motivo per cui Lambda ha cambiato il modo in cui si scrive software cloud.

Domande frequenti su AWS Lambda

Quanto costa Lambda? Paghi due cose: il numero di invocazioni e i GB-secondi consumati (memoria allocata moltiplicata per il tempo di esecuzione). Il Free Tier include una quota mensile sufficiente a sperimentare seriamente senza spendere. Per i numeri esatti, controlla la pagina pricing ufficiale di Lambda, varia per regione e nel tempo.

Cos’è il cold start e quanto rallenta? È il tempo che impiega AWS a preparare l’ambiente di runtime quando una Lambda viene chiamata “fredda” (cioè dopo un periodo di inattività). Tipicamente è tra 100 e 800 millisecondi, dipende dal runtime e dalla dimensione del pacchetto. Per workload sensibili alla latenza esiste la Provisioned Concurrency, che mantiene un certo numero di Lambda sempre calde.

Posso usare Lambda con un container Docker? Sì, dal 2020. Puoi pacchettizzare la tua funzione come immagine Docker (fino a 10 GB) e farla girare su Lambda. È utile quando hai dipendenze pesanti che non stanno nel limite standard dei layer ZIP.

C’è un limite di durata? Sì, 15 minuti. Una singola invocazione di Lambda non può durare più di 15 minuti. Se ti serve di più, devi spezzare il lavoro (es. Step Functions per orchestrare più Lambda in sequenza) o usare un servizio diverso (ECS, Fargate, AWS Batch).

Lambda ha memoria condivisa tra invocazioni? Tecnicamente, due invocazioni successive sulla stessa istanza “calda” possono condividere variabili globali e file in /tmp. Ma non è garantito: AWS può eseguire la prossima invocazione su un’istanza diversa in qualunque momento. Regola: non fare mai affidamento su questo stato. Per dati persistenti, usa DynamoDB o ElastiCache.

Posso debuggare Lambda localmente? Sì, con AWS SAM (Serverless Application Model) o il Serverless Framework. Entrambi simulano l’ambiente Lambda sul tuo PC con Docker. È un workflow molto più rapido del “deploy → test → leggi i log” della console.

Lambda funziona dentro una VPC? Sì. Una Lambda può essere configurata per girare dentro una VPC, dove ha accesso alle risorse private (RDS, ElastiCache, EC2 interne). Tieni presente che le Lambda in VPC hanno qualche complessità in più sul cold start e richiedono il NAT Gateway se devono uscire verso internet, quindi configurala in VPC solo se serve davvero.

Una Lambda è un distributore automatico di codice. La differenza con un servizio tradizionale è una sola: non paghi per tenerla accesa, paghi per la singola “lattina” che esce.

Cambia tutto. Non solo il prezzo, ma il modo di pensare l’architettura. Ogni piccola funzionalità del sistema può diventare una Lambda autonoma, triggerata da un evento. Le applicazioni si scompongono in unità piccole, indipendenti, scalabili da sole.

Se stai preparando il Cloud Practitioner, Lambda è uno dei servizi più presenti nel Domain 3 (Cloud Technology and Services). Per consolidare la base, il Cloud Practitioner Starter Kit include la sezione sui servizi serverless con esempi pratici. Trenta secondi per scaricarlo, zero euro.

E se sei pronto a un percorso strutturato verso l’esame, il corso AWS Cloud Practitioner CLF-C02 in italiano tratta Lambda con la stessa logica di questo articolo, analogia, ciclo evento-codice-risposta, scenari di scelta, lab pratico.

Non esiste “niente server”. Esiste “non sono problemi tuoi”. E quando smettono di essere problemi tuoi, il modo di costruire software cambia di natura.

Ti è stato utile questo articolo? Condividilo con un collega che continua a chiedere “ma allora dove gira il codice?”, la metafora del distributore automatico gli sblocca dieci concetti in cinque minuti.