Che cos'è l'architettura serverless?

L’architettura serverless è un modello di esecuzione cloud in cui il provider esegue il codice su richiesta: nessun server da provisionare o gestire. I server continuano a esistere – semplicemente si smette di affittarli, aggiornarli e scalarli. Si pubblicano funzioni; la piattaforma alloca capacità di calcolo quando arriva un evento e fattura solo ciò che gira davvero.

Punti chiave

Il problema che risolve

Con un deployment tradizionale si affitta capacità prima della domanda: dimensionare l’istanza, configurare l’autoscaling, pagare il tempo di inattività, applicare le patch al sistema operativo. Sbagliare in un senso significa bruciare denaro; nell’altro, perdere richieste proprio al picco di traffico.

In un modello serverless quell’intero ciclo sparisce. Si scrive una funzione, e passare da zero a migliaia di esecuzioni concorrenti è lavoro del provider. Questo è tutto il codice backend necessario per calcolare lato server il voto medio di un film:

// cloud/main.js – una funzione Cloud Code di Back4app
Parse.Cloud.define('averageStars', async (request) => {
  const query = new Parse.Query('Review');
  query.equalTo('movie', request.params.movie);
  const reviews = await query.find();
  const sum = reviews.reduce((acc, r) => acc + r.get('stars'), 0);
  return sum / reviews.length;
});

Niente app Express attorno, niente Dockerfile, niente load balancer. La funzione è l’unità di deployment.

Chiamarla da qualsiasi client

Ogni SDK client invoca la stessa funzione per nome: trasporto, autenticazione e scalabilità li gestisce la piattaforma.

// JavaScript / Node.js — Back4app JS SDK
const params = { movie: 'Inception' };
const rating = await Parse.Cloud.run('averageStars', params);
console.log(`Average rating: ${rating}`);

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('averageStars');
final params = <String, dynamic>{'movie': 'Inception'};
final response = await function.execute(parameters: params);
if (response.success) {
  print('Average rating: ${response.result}');
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("averageStars",
                        parameters: ["movie": "Inception"]) { result in
  switch result {
  case .success(let rating):
    print("Average rating: \(rating)")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("movie" to "Inception")
ParseCloud.callFunctionInBackground<Float>("averageStars", params) { rating, e ->
  if (e == null) {
    Log.d("Cloud", "Average rating: $rating")
  }
}

Come scorre una richiesta serverless

Il ramo da tenere d’occhio è il cold start. Quando non esiste un’istanza calda, la piattaforma deve fare il provisioning di un runtime prima di eseguire il codice: da pochi millisecondi a diversi secondi, a seconda del linguaggio, della dimensione del codice e delle dipendenze. In produzione riguarda solo una piccola frazione delle richieste, perché una funzione invocata con regolarità continua a riutilizzare istanze calde – trascurabile per la maggior parte delle API, ma reale sui percorsi critici per la latenza, ed è il motivo per cui esistono le funzioni edge e le strategie di warm-up.

Serverless vs. container vs. server tradizionali

FaaS e BaaS: le due metà del serverless

“Serverless” copre due modelli complementari, una distinzione formalizzata dall’articolo canonico di Mike Roberts su martinfowler.com. La separazione ha una data di nascita: il calcolo commerciale attivato da eventi è arrivato nel 2014 e in due anni il serverless è passato da idea di ricerca a scelta predefinita in produzione per il lavoro event-driven – ed è il motivo per cui il vocabolario sembra ancora più nuovo delle idee che copre. FaaS (Functions-as-a-Service) significa che la logica lato server resta da scrivere, ma gira su capacità di calcolo stateless, attivata da eventi e interamente gestita: il modello delle “cloud function”. BaaS (Backend-as-a-Service) va oltre: database, autenticazione, archiviazione di file e API si consumano a loro volta come servizi gestiti, così gran parte del codice backend che altrimenti andrebbe scritto sparisce del tutto.

Quasi tutte le applicazioni reali hanno bisogno di entrambi: funzioni per la logica su misura, servizi gestiti per tutto il resto. Questa combinazione è esattamente ciò che una piattaforma BaaS mette insieme. Per approfondire quella metà del modello, vale la pena leggere la nostra guida completa al Backend as a Service.

Casi d’uso tipici del serverless

• API e backend mobile. Il caso dominante: traffico guidato dalle richieste che di notte si ferma e al lancio esplode, esattamente la forma che la tariffazione a esecuzione premia.
• Elaborazione di eventi e dati. Ridimensionare un’immagine al caricamento, validare un record al salvataggio, sincronizzare una modifica verso un sistema di terze parti: reazioni brevi a eventi.
• Job pianificati. Report notturni, attività di pulizia e sincronizzazioni ricorrenti girano come funzioni attivate da cron, senza un server che aspetta tra un’esecuzione e l’altra.
• Funzionalità in tempo reale. Chat, notifiche e dashboard dal vivo combinano funzioni serverless con un’infrastruttura in tempo reale gestita, invece che con server WebSocket costruiti a mano.
• MVP e prototipi. Quando si valida un’idea, non spendere un minuto sull’infrastruttura è tutto il punto: si pubblica una funzione, si ottiene un URL, si spedisce.
• Agenti IA e webhook. Il codice di raccordo tra LLM, provider di pagamento e API SaaS è per natura event-driven e di breve durata: un caso perfetto per il serverless.

Conviene passare al serverless? Matrice decisionale

Sul costo aiutano alcuni riferimenti concreti: le piattaforme serverless fatturano per richiesta più il tempo di calcolo consumato (GB-secondi), senza impegno iniziale, e il piano gratuito di Back4app include 25.000 richieste API al mese, abbastanza per far girare un MVP vero a 0 USD prima di qualsiasi decisione di scalabilità.

Limiti e trade-off

• I cold start. La prima invocazione di una funzione inattiva paga una penalità di provisioning (da meno di 100 ms a oltre un secondo). Mitigazioni: concorrenza calda, bundle più piccoli, runtime edge.
• I limiti di durata dell’esecuzione. Le funzioni sono fatte per lavori brevi; la codifica video o i batch di un’ora appartengono ai container o ai sistemi di job in background.
• Debug e osservabilità più difficili. Non c’è un server in cui entrare via SSH. Si dipende da log, metriche e tracing della piattaforma: conviene valutarli prima di impegnarsi.
• Il vendor lock-in. Le funzioni scritte contro API proprietarie costano care da spostare. Meglio le piattaforme costruite su open source: Cloud Code di Back4app poggia su una base open-source ospitabile in proprio in qualsiasi momento.
• Il costo a regime. Pagare a esecuzione è imbattibile a volumi bassi e irregolari, ma può superare un prezzo fisso per server sotto carico costante e pesante. Conviene rifare i conti quando il traffico si stabilizza.
• L’assenza di stato. Le funzioni non conservano memoria tra un’invocazione e l’altra; sessione e stato applicativo devono vivere in un database o in una cache, un vincolo di progettazione se stai portando codice stateful.

L’architettura serverless su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Offre entrambe le metà in un’unica piattaforma. La metà FaaS è Cloud Code: funzioni JavaScript come averageStars qui sopra, che si pubblicano dalla dashboard o dalla CLI, più trigger di database e job pianificati, senza gateway, policy IAM o infrastruttura da configurare. La metà BaaS arriva già pronta con ogni app Back4app: database, autenticazione degli utenti, archiviazione di file e API REST e GraphQL generate automaticamente. E poiché Back4app poggia su una base open-source, le funzioni scritte sono portabili: lo stesso stack si può ospitare in proprio più avanti, il che toglie di mezzo l’obiezione del lock-in che pesa sulle piattaforme serverless legate a un singolo provider.