Serverless — Cheat Sheet

Tag: serverless, aws, lambda, faas, cloud, event-driven

Livello: intermedio

TL;DR: Modello di esecuzione cloud in cui il provider gestisce dinamicamente l'allocazione delle risorse. Si paga solo per il tempo di calcolo effettivo.

Concetti chiave

FaaS (Function as a Service): il codice viene eseguito in container stateless e temporanei.

Event-driven: le funzioni sono attivate da eventi (richieste HTTP, code di messaggi, modifiche su storage).

Auto-scaling nativo: il sistema scala automaticamente da zero a migliaia di istanze concorrenti.

Pay-as-you-go: fatturazione granulare basata su millisecondi di esecuzione e numero di invocazioni.

Stateless: ogni esecuzione è indipendente. Lo stato persistente va salvato su servizi esterni.

Cold start: latenza iniziale dovuta all'allocazione del container alla prima invocazione o dopo inattività.

Vendor lock-in: forte dipendenza dalle API e dall'ecosistema specifico del cloud provider scelto.

Domande tipiche e risposte pronte

Q: Come gestisci il problema del cold start in un'applicazione Serverless?R: Ottimizzo le dipendenze e scelgo linguaggi a rapido avvio come Node.js o Go. Se la latenza è critica, abilito la provisioned concurrency.

Q: Quali sono i limiti fisici principali di una AWS Lambda?R: Timeout massimo di 15 minuti, payload limitato per le richieste sincrone (6MB) e limiti di concorrenza a livello di account.

Q: Quando eviteresti di usare un'architettura Serverless?R: Per processi batch di lunghissima durata o per applicazioni con traffico costantemente elevato, dove container tradizionali risultano più economici.

Insidie e errori comuni

Sottovalutare i costi su scala: ad altissimi volumi costanti, istanze EC2 o container possono costare meno.

Monoliti dentro funzioni: caricare un intero framework pesante dentro una singola funzione rallenta drasticamente l'avvio.

Gestione degli errori a cascata: retry infiniti su code senza Dead Letter Queue (DLQ) generano loop infiniti e picchi di spesa.

Eccessivo accoppiamento: non separare la business logic dal codice specifico dell'handler del provider.

Snippet e comandiTypeScript

// Esempio handler AWS Lambda in TypeScript
export const handler = async (event: any, context: any) => {
  try {
    const data = JSON.parse(event.body);
    // Business logic isolata
    return {
      statusCode: 200,
      body: JSON.stringify({ message: "Operazione completata", data })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: "Errore interno del server" })
    };
  }
};

Bash

# Deploy di un servizio con Serverless Framework
serverless deploy --stage production

# Lettura dei log di una specifica funzione
serverless logs -f myFunctionName -t

Da ripassare

[ ] Pattern architetturali: API Gateway + Lambda + DynamoDB

[ ] Relazione tra memoria allocata e CPU disponibile nelle funzioni

[ ] Sistemi di distributed tracing (AWS X-Ray, Datadog)

[ ] Pattern di messaggistica: SNS, SQS ed EventBridge

Riferimenti

AWS Lambda Developer Guide

Serverless Framework Documentation

Jarvis Interviews
Jarvis