---
term: 'Architettura serverless'
seoTitle: 'Architettura serverless: che cos''è? Guida completa'
headline: 'Che cos''è l''architettura serverless?'
slug: architettura-serverless
category: cloud-architecture
shortDefinition: 'L''architettura serverless è un modello di esecuzione cloud in cui il provider esegue il codice su richiesta: nessun server da provisionare o gestire.'
relatedTerms:
  - baas-vs-custom-backend
  - cloud-code-serverless-functions
  - serverless-cold-starts
  - edge-computing-edge-functions
  - no-ops-development
contrastsWith:
  - microservices-vs-monolith
faq:
  - question: 'Serverless significa che non ci sono server?'
    answer: 'No: i server continuano a eseguire il codice. "Serverless" significa che restano invisibili, perché il provider cloud li possiede, li provisiona, li aggiorna e li scala. Si pubblicano funzioni e la piattaforma decide dove e quando eseguirle. Dal punto di vista di chi sviluppa non c''è nulla da dimensionare, riavviare o mantenere.'
  - question: 'Il serverless costa meno dei server tradizionali?'
    answer: 'Per carichi a picchi o di basso volume di solito sì: si paga per richiesta e per GB-secondo di esecuzione, e la fattura scende a zero quando non gira nulla. Per traffico costante ad alto volume un container sempre attivo o un''istanza riservata costa spesso meno, perché il prezzo per invocazione su milioni di richieste regolari può superare una tariffa fissa per server. Conviene modellare la curva di traffico reale prima di scegliere.'
  - question: 'Quali sono gli svantaggi dell''architettura serverless?'
    answer: 'I trade-off principali sono i cold start (di norma da meno di 100 ms a oltre 1 secondo alla prima invocazione di una funzione inattiva), i limiti di durata dell''esecuzione, un debug locale e un''osservabilità più difficili e un potenziale vendor lock-in se le funzioni usano API specifiche del provider. Le piattaforme costruite su open source, come Cloud Code di Back4app, attenuano il rischio di lock-in perché lo stesso stack si può ospitare in proprio.'
  - question: 'Meglio il serverless o i container?'
    answer: 'Meglio il serverless dei container Docker per carichi event-driven, a picchi o imprevedibili, e per team piccoli che non vogliono gestire infrastruttura. Meglio i container per processi di lunga durata, runtime personalizzati o servizi ad alto volume costante, dove la capacità sempre attiva costa meno. Molti sistemi in produzione combinano entrambi: serverless per le API e i gestori di eventi, container per i carichi di fondo regolari.'
  - question: 'I cold start sono ancora un problema?'
    answer: 'Molto meno di un tempo. In produzione i cold start riguardano solo una piccola frazione delle invocazioni – una funzione invocata con regolarità riutilizza istanze calde per centinaia di migliaia di chiamate – e durano di norma da pochi millisecondi a circa un secondo, a seconda del runtime e della dimensione del codice. Sui percorsi critici per la latenza si possono attenuare con concorrenza calda, dipendenze più leggere o funzioni edge. Per API e backend mobile tipici si notano di rado.'
  - question: 'Qual è la differenza tra FaaS e BaaS?'
    answer: 'Il FaaS (Functions-as-a-Service) esegue il codice lato server che resta da scrivere: funzioni stateless attivate da eventi, come Cloud Code di Back4app. Il BaaS (Backend-as-a-Service) va oltre: database, autenticazione, archiviazione di file e API si consumano come servizi già pronti, così gran parte del codice backend sparisce del tutto. Sono le due metà complementari del modello serverless, e quasi tutte le applicazioni reali le usano entrambe.'
  - question: 'Quando NON conviene usare il serverless?'
    answer: 'Meglio evitarlo per job di lunga durata che superano i limiti di esecuzione, per carichi che richiedono hardware specializzato o runtime personalizzati, per sistemi critici per la latenza che non tollerano alcun cold start e per traffico costante ad alto volume, dove i server sempre attivi costano meno. Anche requisiti normativi di controllo totale dell''infrastruttura possono escluderlo.'
  - question: 'Quali linguaggi di programmazione possono usare le funzioni serverless?'
    answer: 'Dipende dai runtime che la piattaforma mette a disposizione: JavaScript/Node.js è il più supportato in assoluto, e quasi tutte le piattaforme aggiungono opzioni come Python, Go o Java. Su Back4app le funzioni Cloud Code si scrivono in JavaScript su un runtime Node.js gestito, quindi lo stesso linguaggio del frontend web esegue la logica di backend. Qualunque sia la piattaforma, i client non ne risentono: chiamano le funzioni per nome via HTTPS o tramite un SDK.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'CNCF Serverless Whitepaper'
    url: 'https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf'
  - name: 'Serverless computing (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Serverless_computing'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: 'Esegui funzioni serverless senza prima assemblare la piattaforma'
  text: 'Cloud Code su Back4app ti dà funzioni serverless con database, autenticazione e API già pronti – nessun gateway da configurare, nessuna policy IAM da scrivere. Pubblica la tua prima funzione in pochi minuti sul piano gratuito.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-30'
translationKey: serverless-architecture
---

**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

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Codice eseguito su capacità di calcolo on demand gestita dal provider, senza provisioning di server |
| Problema che risolve | Pianificazione della capacità, costo dei server inattivi e gestione dell'infrastruttura |
| Modello di fatturazione | Per richiesta + per GB-secondo di esecuzione; scende a zero quando è tutto fermo |
| A cosa fare attenzione | Cold start, limiti di durata dell'esecuzione, lock-in del provider |
| Equivalente su Back4app | Le funzioni Cloud Code: si pubblica il codice, Back4app lo esegue |

## 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:

```javascript
// 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:**

```javascript
// 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
// 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}');
}
```

**Swift:**

```swift
// 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)
  }
}
```

**Kotlin:**

```kotlin
// 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

```mermaid
flowchart LR
  accTitle: Flusso di una richiesta serverless
  accDescr: Un client chiama un endpoint gestito; la piattaforma esegue la funzione su un'istanza calda oppure ne provisiona una con un cold start, legge il database gestito, restituisce la risposta e scende a zero dopo un periodo di inattività.
  A[App client] --> B[Endpoint HTTPS gestito]
  B --> C{Istanza calda<br/>disponibile?}
  C -- sì --> D[Esegui la funzione]
  C -- no --> E[Cold start:<br/>provisioning del runtime] --> D
  D --> F[(Database gestito)]
  D --> G[Risposta al client]
  D -. dopo l'inattività .-> H[Scende a zero<br/>costo: 0 USD]
```

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](https://martinfowler.com/articles/serverless.html). 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

| Dimensione | Serverless | Container (Kubernetes) | VM tradizionali |
| --- | --- | --- | --- |
| Unità di deployment | Funzione | Immagine di container | Immagine di macchina |
| Scalabilità | Automatica, per richiesta, fino a zero | Automatica, ma il cluster va configurato e pagato | Manuale o gruppi di autoscaling |
| Costo a riposo | 0 USD | Il cluster continua a girare | L'istanza continua a girare |
| Cold start | Sì (da ms a secondi) | No (i pod restano caldi) | No |
| Processi di lunga durata | Limitati dai timeout di esecuzione | Sì | Sì |
| Carico operativo | Nessuno | Rilevante (cluster, aggiornamenti, capacità) | Il più alto (sistema operativo, patch, alta disponibilità) |
| Ideale per | Carichi event-driven, a picchi o imprevedibili | Carico costante, runtime personalizzati | Sistemi legacy, controllo totale |

## 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](https://martinfowler.com/articles/serverless.html). 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](https://www.back4app.com/backend-as-a-service-baas).

## 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

| Scegliere il serverless quando… | Scegliere server sempre attivi quando… |
| --- | --- |
| Il traffico è a picchi, imprevedibile o di basso volume | Il traffico è costante e ad alto volume (il sempre attivo costa meno) |
| Serve lanciare in fretta con un team piccolo | Ci sono processi di lunga durata che superano i timeout delle funzioni |
| I mattoni standard (autenticazione, CRUD, archiviazione) coprono quasi tutto | Servono runtime personalizzati, GPU o hardware specializzato |
| Non ci sono risorse DevOps dedicate | Le normative impongono il controllo totale dell'infrastruttura |
| Il costo deve seguire l'uso, partendo da 0 USD | Una latenza di coda sotto i 10 ms è irrinunciabile su ogni richiesta |

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](https://www.back4app.com/docs/get-started/cloud-functions)**: 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.