---
term: 'IaaS vs. PaaS vs. CaaS vs. FaaS vs. BaaS vs. mBaaS vs. SaaS'
seoTitle: 'IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS, SaaS: guida completa'
headline: 'Modelli di servizio cloud a confronto: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS e SaaS'
slug: modelli-di-servizio-cloud
category: cloud-architecture
shortDefinition: 'Lo spettro dei modelli di servizio cloud è una scala – IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS – ordinata in base a quanto ne gestisce il provider.'
relatedTerms:
  - infrastructure-as-a-service
  - paas-vs-baas
  - baas-vs-serverless
  - mbaas-vs-baas
  - baas-vs-custom-backend
  - serverless-architecture
  - containerization
contrastsWith:
  - paas-vs-baas
aboutTerms:
  - 'Infrastructure-as-a-Service (IaaS)'
  - 'Containers-as-a-Service (CaaS)'
  - 'Platform-as-a-Service (PaaS)'
  - 'Functions-as-a-Service (FaaS)'
  - 'Backend-as-a-Service (BaaS)'
  - 'Mobile Backend-as-a-Service (mBaaS)'
  - 'Software-as-a-Service (SaaS)'
faq:
  - question: 'Qual è la differenza principale tra IaaS, PaaS e SaaS?'
    answer: 'Chi gestisce cosa. IaaS affitta infrastruttura – macchine virtuali, archiviazione, reti – e tutto ciò che sta dal sistema operativo in su resta a carico del cliente. PaaS affitta una piattaforma gestita: si portano codice applicativo e dati, il provider gestisce il resto. SaaS consegna software finito, da usare e basta. Ogni piolo in più scambia controllo con velocità e minor carico operativo.'
  - question: 'Dove si collocano CaaS, FaaS e BaaS tra IaaS e SaaS?'
    answer: 'Sui pioli che il trio classico salta. CaaS sta tra IaaS e PaaS: si consegnano container, il provider gestisce l''orchestrazione. FaaS sta sopra PaaS: si consegnano singole funzioni, eseguite a ogni evento. BaaS va più in là pur restando programmabile: il backend stesso – database, autenticazione, archiviazione, API – arriva pre-costruito, quindi le funzionalità standard non richiedono alcun codice lato server.'
  - question: 'BaaS significa Backend-as-a-Service o Backup-as-a-Service?'
    answer: 'Nello sviluppo di applicazioni, BaaS significa quasi sempre Backend-as-a-Service: un backend applicativo pre-costruito consumato tramite SDK. Una minoranza di contesti di archiviazione enterprise usa la stessa sigla per Backup-as-a-Service, che non c''entra nulla: backup gestiti dei dati. Se il discorso riguarda app mobili, API o piattaforme applicative, BaaS va letto come backend. Il contesto risolve l''ambiguità; questa pagina copre il significato backend.'
  - question: 'Qual è la differenza tra CaaS e PaaS?'
    answer: 'L''unità che si consegna al provider. Con CaaS si consegnano container – qualsiasi linguaggio, qualsiasi stack, impacchettati a modo proprio – e si mantiene il controllo sulle scelte di orchestrazione. Con PaaS si consegna codice applicativo e si accettano i runtime e le convenzioni supportati dalla piattaforma, in cambio di un flusso di deployment più semplice. CaaS si adatta a microservizi e stack poliglotti; PaaS alle app standard che vogliono il minimo di cerimoniale.'
  - question: 'FaaS è la stessa cosa di serverless?'
    answer: 'FaaS è una metà del serverless, non un sinonimo. La definizione canonica – di Mike Roberts su martinfowler.com – tratta il serverless come un ombrello che copre sia FaaS (le proprie funzioni, eseguite su richiesta) sia BaaS (servizi backend pre-costruiti). Nel parlato comune "serverless" indica spesso solo FaaS, ed è per questo che i termini si ingarbugliano.'
  - question: 'Qual è la differenza tra BaaS e mBaaS?'
    answer: 'mBaaS è il punto in cui la categoria è nata: un backend pre-costruito pensato specificamente per le app mobili, con notifiche push, SDK consapevoli del dispositivo e sincronizzazione offline come funzionalità di primo livello. Quando anche le app web sono diventate client-first, il modello si è generalizzato e la m è caduta. Oggi ogni mBaaS serio serve il web allo stesso modo, quindi i due termini indicano perlopiù le stesse piattaforme con accenti diversi.'
  - question: 'Quale modello di servizio cloud costa meno?'
    answer: 'Dipende dalla forma del carico di lavoro, non dal modello. FaaS costa meno con traffico basso o a picchi, perché il costo a riposo è zero, e diventa caro sotto carico pesante e costante. IaaS ha il miglior prezzo unitario grezzo su scala grande e stabile, ma porta con sé il costo nascosto del team che lo manda avanti. CaaS, PaaS e BaaS stanno nel mezzo: scambiano un margine di piattaforma con tempo di ingegneria eliminato, che per i team piccoli è di solito la voce di costo dominante.'
  - question: 'Si possono combinare più modelli di servizio?'
    answer: 'Lo fa quasi ogni azienda reale. Uno stack tipico: SaaS per gli strumenti aziendali, BaaS o PaaS per far girare il prodotto, FaaS per il collante guidato dagli eventi, CaaS per i servizi containerizzati che richiedono controllo sull''orchestrazione e IaaS per il raro carico specializzato. I modelli sono pioli su cui collocare ogni carico di lavoro individualmente: l''abilità pratica sta nell''abbinare ciascun carico al piolo sufficiente meno costoso.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'The NIST Definition of Cloud Computing (SP 800-145)'
    url: 'https://csrc.nist.gov/pubs/sp/800/145/final'
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'As a service (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/As_a_service'
  - name: 'Kubernetes documentation — overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: 'Parti dal piolo più alto'
  text: 'Back4app colloca il progetto sul piolo BaaS dal primo giorno – database, autenticazione, archiviazione e API pre-costruiti, con le funzioni Cloud Code quando serve anche il piolo FaaS. Costruito su open source, così tornare giù resta possibile.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-30'
translationKey: iaas-paas-baas-faas
---

**Lo spettro dei modelli di servizio cloud è una scala – IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS – ordinata in base a quanto ne gestisce il provider.** Ogni "aaS" risponde alla stessa domanda tracciando la linea in un punto diverso: *si costruisce sopra questa linea; sotto gestiamo noi.* Quasi tutte le spiegazioni si fermano al trio classico che la definizione del NIST ha formalizzato – IaaS, PaaS, SaaS – e saltano i pioli su cui vivono davvero i prodotti moderni. Questa guida li copre tutti e sette, definisce ciascuno per bene e poi confronta le coppie che si confondono sul serio. Scegliere il piolo significa scegliere che cosa il team passerà la vita a mantenere.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| La scala in una riga | IaaS: affittare le macchine · CaaS: affittare l'orchestrazione · PaaS: affittare la piattaforma · FaaS: affittare la singola esecuzione · BaaS: affittare il backend · mBaaS: affittare il backend mobile · SaaS: affittare l'app finita |
| La vera variabile | Dove passa la linea tra ciò che gestisce il cliente e ciò che gestisce il provider |
| L'unità che si distribuisce | VM → container → applicazione → funzione → modello di dati → niente |
| Serverless? | L'ombrello sopra FaaS *e* BaaS, non un piolo a sé |
| Qual è il migliore | Domanda sbagliata – conviene abbinare ogni carico di lavoro al piolo sufficiente meno costoso |
| La tendenza | Ogni anno i team partono più in alto sulla scala |

## Cosa significa "avviare il backend" a ogni piolo

```bash
# Lo stesso compito – un backend che serve richieste – un piolo alla volta
# IaaS – si ottengono le macchine:
$ ssh admin@vm-01              # poi: installare, configurare, patchare, scalare, monitorare…
# CaaS – si ottiene l'orchestrazione:
$ docker push registry/api:v1  # i propri container; scheduler, rete e scalabilità del provider
# PaaS – si ottiene una piattaforma:
$ git push platform main       # il proprio codice; server, runtime e scalabilità del provider
# FaaS – si ottiene un runtime per evento:
$ deploy functions/api.js      # le proprie funzioni; su richiesta, scalano a zero
# BaaS / mBaaS – si ottiene il backend stesso:
#   niente da distribuire – autenticazione, database e API sono già in funzione
# SaaS – si ottiene il prodotto finito:
#   niente da costruire – basta accedere e usarlo
```

Il piolo BaaS merita una prova, perché "niente da distribuire" suona come marketing. Salvare un ordine su un backend di produzione – schema, API, controllo degli accessi e scalabilità tutti lato provider – è una sola chiamata lato client:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const order = new Parse.Object('Order');
order.set('total', 129.9);
order.set('status', 'paid');
await order.save(); // schema, API, auth, scaling: all the rungs below you
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final order = ParseObject('Order')
  ..set('total', 129.9)
  ..set('status', 'paid');
await order.save(); // schema, API, auth, scaling handled below you
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var order = Order()
order.total = 129.9
order.status = "paid"
order.save { result in
  if case .success = result {
    print("saved — the platform ran every layer underneath")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val order = ParseObject("Order").apply {
  put("total", 129.9)
  put("status", "paid")
}
order.saveInBackground { e ->
  if (e == null) Log.d("Order", "saved — platform ran every layer underneath")
}
```

## I sette modelli su un'unica scala

```mermaid
flowchart LR
  accTitle: La scala as-a-service con sette pioli
  accDescr: Otto gradini, dall'on-premises attraverso IaaS, CaaS, PaaS, FaaS e BaaS con la sua specializzazione mobile mBaaS, fino a SaaS – ognuno affitta di più dal provider; le macchine, l'orchestrazione dei container, la piattaforma, le funzioni eseguite su richiesta, il backend e infine l'applicazione finita.
  A["On-premises"] --> B["IaaS<br/>affittare le macchine"]
  B --> C["CaaS<br/>affittare l'orchestrazione"]
  C --> D["PaaS<br/>affittare la piattaforma"]
  D --> E["FaaS<br/>affittare la singola esecuzione"]
  E --> F["BaaS · mBaaS<br/>affittare il backend"]
  F --> G["SaaS<br/>affittare l'app finita"]
```

La [definizione di cloud computing del NIST](https://csrc.nist.gov/pubs/sp/800/145/final) ha formalizzato i tre pioli classici nel 2011 – IaaS ("fornire elaborazione, archiviazione, reti"), PaaS ("distribuire applicazioni create dal consumatore con gli strumenti supportati dal provider"), SaaS ("usare le applicazioni del provider") – prima che CaaS, FaaS e BaaS esistessero come categorie. I pioli più recenti si incastrano nei vuoti lasciati dal NIST: CaaS tra IaaS e PaaS, FaaS e BaaS tra PaaS e SaaS – sempre programmabili, ma con una parte sempre più piccola del programma che appartiene al cliente.

## Chi gestisce cosa: la matrice delle responsabilità

Tutto l'argomento in una tabella. Leggere una colonna dall'alto in basso mostra che cosa un modello lascia sul piatto del cliente:

| Livello | On-prem | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Logica di business | Cliente | Cliente | Cliente | Cliente | Cliente (come funzioni) | Solo la logica personalizzata | Provider |
| Funzionalità backend (auth, CRUD, archiviazione, push) | Cliente | Cliente | Cliente | Cliente | Cliente | **Provider** | Provider |
| Impacchettamento dell'app e runtime | Cliente | Cliente | Cliente (container) | Provider | Provider | Provider | Provider |
| Orchestrazione e scalabilità | Cliente | Cliente | **Provider** | Provider | Provider (fino a zero) | Provider | Provider |
| Sistema operativo e patch | Cliente | Cliente | Provider | Provider | Provider | Provider | Provider |
| Server, rete, hardware | Cliente | **Provider** | Provider | Provider | Provider | Provider | Provider |
| Dati e policy di accesso | Cliente | Cliente | Cliente | Cliente | Cliente | Cliente | **Sempre il cliente** |

Due cose che la matrice rende visibili e che la prosa di solito nasconde: l'ultima riga non si trasferisce mai – dati e pratiche di identità restano del cliente a ogni piolo, anche su SaaS – e il nome di ogni modello è semplicemente il livello più alto in cui compare "Provider".

## Che cos'è IaaS (Infrastructure-as-a-Service)?

IaaS affitta a ore infrastruttura virtualizzata: macchine, archiviazione a blocchi, reti. Tutto ciò che sta sopra l'hypervisor è del cliente – sistema operativo, patch, runtime, logica di scalabilità e la reperibilità alle 3 di notte. È il piolo del massimo controllo e della massima superficie operativa, trattato a fondo nella [voce IaaS](/glossary/it/infrastructure-as-a-service/).

| | Profilo IaaS |
| --- | --- |
| Cosa si distribuisce | Macchine virtuali e tutto ciò che ci gira sopra |
| Cosa gestisce il provider | Hardware fisico, virtualizzazione, rete |
| Forma dei prezzi | Per ora-risorsa, in uso o a riposo |
| Sceglierlo quando | Hardware o runtime speciali, controllo stretto dell'infrastruttura, lift-and-shift |
| Lasciar perdere quando | Il personale ops costa più di quanto valga il controllo |

Il test onesto del piolo è che aspetto ha il giorno due. Su IaaS il giorno due significa finestre di patch del sistema operativo, aggiornamenti del kernel, allarmi di spazio su disco, audit dei security group, pianificazione della capacità e la costruzione di quel monitoring che ogni piolo superiore include gratis. Niente di tutto questo è il prodotto. Il piolo si ripaga in esattamente tre situazioni: hardware o runtime che nessuna piattaforma offre, regimi di conformità che impongono il controllo dell'infrastruttura e una scala costante abbastanza grande perché il prezzo unitario grezzo batta i margini del gestito *dopo* aver messo a bilancio il team che lo manda avanti – un'asticella molto più alta di quanto la maggior parte dei team immagini.

## Che cos'è CaaS (Containers-as-a-Service)?

CaaS affitta il livello che quasi tutte le spiegazioni saltano: i servizi si impacchettano in [container](/glossary/it/containerizzazione/) – qualsiasi linguaggio, qualsiasi stack – e il provider gestisce lo scheduler, la rete tra i servizi e la macchineria della scalabilità, di solito [Kubernetes](/glossary/it/kubernetes/) o un equivalente. Si colloca deliberatamente tra IaaS e PaaS: più astratto delle macchine, meno prescrittivo di una piattaforma. Questo lo rende la casa naturale dei [microservizi](/glossary/it/microservizi-vs-monolite/) e dei parchi poliglotti che mal sopporterebbero le convenzioni di un PaaS.

| | Profilo CaaS |
| --- | --- |
| Cosa si distribuisce | Immagini di container, manifest di deployment |
| Cosa gestisce il provider | Control plane di orchestrazione, nodi, rete |
| Forma dei prezzi | Per nodo/cluster o per container in esecuzione |
| Sceglierlo quando | Microservizi, stack poliglotti, controllo sull'orchestrazione senza gestire il cluster |
| Lasciar perdere quando | Una sola app standard – un PaaS o un BaaS è meno macchineria per lo stesso risultato |

La sottigliezza che separa CaaS da un tutorial su [Kubernetes](/glossary/it/kubernetes/) gestito: ciò che si trasferisce è il *control plane* – scheduler, etcd, API server, salute dei nodi – mentre tutto ciò che si esprime in immagini e manifest resta del cliente: igiene delle immagini di base, resource request, liveness probe, strategia di deployment, topologia dei servizi. È una disciplina vera, ed è proprio per questo che il piolo esiste come offerta a sé: serve ai team che hanno bisogno di quella espressività ma nessuna voglia di gestire la macchineria sottostante. Il container stesso è l'argomento della portabilità – la stessa immagine gira su qualsiasi orchestratore conforme, il che mantiene CaaS tra i pioli a più basso vendor lock-in della scala.

## Che cos'è PaaS (Platform-as-a-Service)?

PaaS affitta una piattaforma applicativa gestita: si spinge il codice, il provider fornisce il runtime, la scalabilità e il sistema operativo sottostante. Lo scambio è convenzione in cambio di cerimoniale – linguaggi supportati e modi di fare della piattaforma in cambio di un deployment con `git push`. Il punto critico che PaaS *non* elimina: il cliente scrive e possiede ancora l'intera applicazione backend – autenticazione, endpoint, validazione, tutto – una distinzione che la [voce PaaS vs. BaaS](/glossary/it/paas-vs-baas/) seziona.

| | Profilo PaaS |
| --- | --- |
| Cosa si distribuisce | Codice applicativo |
| Cosa gestisce il provider | Runtime, sistema operativo, server, scalabilità |
| Forma dei prezzi | Per istanza/piano |
| Sceglierlo quando | App server su misura in cui la logica backend è il prodotto |
| Lasciar perdere quando | Si stanno scrivendo funzionalità standard che un BaaS già include |

Il contratto PaaS ha plasmato una generazione di buone abitudini – app twelve-factor, configurazione nell'ambiente, processi stateless, log come flussi – perché la piattaforma *impone* ciò che prima era solo un consiglio. Il suo confine è altrettanto istruttivo: la piattaforma esegue l'applicazione ma non sa nulla di cosa ci sia dentro, quindi ogni preoccupazione del backend – [sessioni](/glossary/it/gestione-delle-sessioni/), permessi, migrazioni, [rate limiting](/glossary/it/rate-limiting-api/) – resta codice da scrivere, testare e patchare. Ed è il segnale del piolo sbagliato: se gran parte del codice ospitato su PaaS reimplementa utenti, CRUD e upload di file, si sta costruendo a mano il piolo di sopra.

## Che cos'è FaaS (Functions-as-a-Service)?

FaaS affitta capacità di calcolo a evento: si distribuiscono singole funzioni, il provider esegue ogni invocazione su richiesta e scala a zero tra una e l'altra. È l'espressione più pura del [calcolo serverless](/glossary/it/architettura-serverless/) – niente gira, e niente si paga, finché non succede qualcosa. I costi sono architetturali: [cold start](/glossary/it/cold-start-serverless/), limiti di esecuzione e un'assenza di stato che spinge altrove tutta la persistenza. Il confronto tra le funzioni e una flotta di servizi propria è la questione [funzioni vs. microservizi](/glossary/it/funzioni-serverless-vs-microservizi/).

| | Profilo FaaS |
| --- | --- |
| Cosa si distribuisce | Singole funzioni |
| Cosa gestisce il provider | Tutto il resto, a ogni invocazione |
| Forma dei prezzi | Per invocazione + tempo di esecuzione; a riposo = zero |
| Sceglierlo quando | Lavoro guidato dagli eventi: webhook, job, pipeline, collante |
| Lasciar perdere quando | Carico pesante e costante – il prezzo per invocazione si ribalta |

L'assenza di stato è il vincolo portante: una funzione può essere distrutta dopo qualsiasi invocazione, quindi tutto ciò che è durevole – sessioni, file, code, dati – deve vivere in servizi *intorno* alla funzione. Portato alle sue conseguenze, quel vincolo assembla in silenzio un BaaS: funzioni per la logica, servizi gestiti per tutto ciò che ha uno stato. È per questo che i due pioli sono convergiti nella pratica, ed è per questo che esistono runtime open source (Knative, OpenFaaS) per i team che vogliono il modello a evento sulla propria orchestrazione. I prezzi seguono la stessa logica a forma di evento – gratis a riposo è imbattibile per il traffico a picchi e punitivo per il carico costante, il ribaltamento che ogni fattura FaaS prima o poi insegna.

## Che cos'è BaaS (Backend-as-a-Service)?

BaaS affitta il backend stesso. Il database, l'[autenticazione](/glossary/it/autenticazione-vs-autorizzazione/), l'archiviazione di file, le [API generate automaticamente](/glossary/it/api-generate-automaticamente/) e le notifiche push arrivano pre-costruiti e gestiti, consumati dagli [SDK client](/glossary/backend-sdk/): per le funzionalità standard non c'è alcun codice lato server da scrivere, come dimostra l'esempio qui sopra. La logica personalizzata gira in [funzioni cloud](/glossary/it/cloud-code-funzioni-serverless/) integrate, ed è per questo che le piattaforme BaaS mature contengono il piolo FaaS invece di farci concorrenza. La versione costruire-o-comprare di questa decisione ha [una voce dedicata](/glossary/it/baas-vs-backend-personalizzato/), e la questione del lock-in – la debolezza onesta del piolo – dipende dal fatto che la piattaforma sia [open source o proprietaria](/glossary/it/baas-open-source-vs-proprietario/).

| | Profilo BaaS |
| --- | --- |
| Cosa si distribuisce | Un modello di dati, regole di sicurezza, funzioni personalizzate – spesso nient'altro |
| Cosa gestisce il provider | L'intero backend standard, dietro SDK e API |
| Forma dei prezzi | Piano gratuito + consumo/piani |
| Sceglierlo quando | Backend applicativi standard – utenti, dati, file – e la velocità conta |
| Lasciar perdere quando | La logica backend *è* il prodotto, o i requisiti sono molto lontani dallo standard |

Ciò che BaaS elimina è *l'infrastruttura e il boilerplate*, non l'ingegneria: il [modello di dati](/glossary/it/modellazione-dei-dati/), le [regole di sicurezza](/glossary/it/liste-di-controllo-degli-accessi-acl/) e la logica di business restano decisioni che nessuna piattaforma prende al posto del cliente. L'economia del piolo è la più netta della scala – minuti per avere un backend funzionante, costo iniziale quasi nullo – e lo è altrettanto il suo rischio strutturale: su una piattaforma proprietaria lo schema dei dati, l'autenticazione e le funzioni vivono tutti in una forma decisa dal vendor, il che rende BaaS il lock-in più forte tra i pioli programmabili. La variante open source dissolve esattamente questo: quando la stessa piattaforma si può ospitare in proprio, andarsene significa traslocare, non riscrivere. L'era dell'IA ha anche allargato il pubblico del piolo: i frontend generati hanno bisogno di backend veri in fretta, e uno pre-costruito e con i permessi già impostati è la forma che calza.

## Che cos'è mBaaS (Mobile Backend-as-a-Service)?

mBaaS è il punto in cui la categoria BaaS è nata: un backend pre-costruito pensato specificamente per le app mobili, con [notifiche push](/glossary/it/notifiche-push/), SDK consapevoli del dispositivo e [sincronizzazione offline](/glossary/offline-first-data-sync/) come funzionalità di primo livello e non come aggiunte. Quando anche le single-page app web sono diventate client-first, il modello si è generalizzato e la *m* è caduta senza far rumore: oggi ogni piattaforma seria serve web e mobile dallo stesso backend. Quando la distinzione conta ancora – e quando è solo un residuo storico – è l'argomento della [voce mBaaS vs. BaaS](/glossary/it/mbaas-vs-baas/).

| | Profilo mBaaS |
| --- | --- |
| Cosa si distribuisce | Lo stesso di BaaS, tramite SDK nativi mobili |
| Cosa gestisce il provider | Il backend, più l'impiantistica mobile: gateway di push, stato del dispositivo, sync |
| Forma dei prezzi | Come BaaS |
| Sceglierlo quando | Prodotti mobile-first che vivono di push, offline e stato per dispositivo |
| Lasciar perdere quando | Mai separatamente da BaaS – è una specializzazione, non un rivale |

La *m* si guadagna ancora la sua lettera in tre punti. Le notifiche push non sono una chiamata alle API ma una relazione con i gateway delle piattaforme (APNs, FCM) – registrazione dei token, targeting dei dispositivi, semantica di consegna – che una piattaforma di calibro mBaaS gestisce da capo a fondo. La sincronizzazione offline-first significa che l'SDK è una macchina a stati, non un sottile involucro HTTP: persistenza locale, scritture in coda, gestione dei conflitti al ritorno della connettività. E lo stato per dispositivo (installazioni, canali, segmenti) è un modello di dati che le app web semplicemente non hanno. Se questi tre paragrafi descrivono il prodotto, l'eredità mobile della piattaforma conta; altrimenti BaaS e mBaaS sono lo stesso acquisto.

## Che cos'è SaaS (Software-as-a-Service)?

SaaS affitta software finito: basta accedere e usarlo. È l'unico piolo della scala che si *consuma* invece di *costruirci sopra*, ed è per questo che confrontarlo con gli altri è un cambio di categoria: i primi sei modelli rispondono a "quanta parte dello stack del mio prodotto gestisco io?"; SaaS risponde a "questa cosa deve proprio far parte del mio prodotto?". CRM, posta e analytics sono SaaS. Nel momento in cui uno strumento ha bisogno di logica personalizzata al suo interno, si è caduti dal piolo SaaS e ne serve uno più in basso.

| | Profilo SaaS |
| --- | --- |
| Cosa si distribuisce | Niente – si configura |
| Cosa gestisce il provider | Tutto, tranne i dati e la policy di accesso del cliente |
| Forma dei prezzi | Per utente/mese |
| Sceglierlo quando | Il problema è già prodotto da qualcuno e non è un fattore di differenziazione |
| Lasciar perdere quando | Serve un comportamento su misura che la roadmap del vendor non condivide |

In questo confronto SaaS conta soprattutto come *confine*: definisce che aspetto ha il "completamente gestito" quando non resta più niente da programmare, la direzione verso cui ogni altro piolo sale da due decenni. Fissa anche il tetto della promessa dei pioli su cui si costruisce – più un BaaS si avvicina a "il backend del tuo prodotto sembra SaaS dal primo giorno", più l'ingegneria che resta è esattamente la parte che differenzia. La dipendenza è il prezzo: roadmap, prezzi e portabilità dei dati stanno dalla parte del vendor, e i dati e la policy di accesso sono le uniche righe che non cambiano mai lato.

## Come è cresciuta la scala

| Epoca | Che cosa è comparso | Che cosa ha astratto |
| --- | --- | --- |
| 2006–2009 | IaaS, poi PaaS | Comprare hardware; poi gestire server |
| 2011 | Il NIST formalizza IaaS/PaaS/SaaS · mBaaS emerge per le app mobili | Le definizioni; poi il backend mobile |
| 2013–2014 | I container diventano mainstream → CaaS · primi runtime FaaS | Le immagini macchina; poi il server sempre acceso |
| 2015–2020 | mBaaS si generalizza in BaaS · si conia l'ombrello "serverless" | L'inquadramento solo mobile; poi il server come concetto |
| Oggi | I team scelgono per impostazione predefinita il piolo sufficiente più alto | Il prossimo candidato: il boilerplate stesso |

Lo schema di due decenni è a senso unico: ogni nuovo modello astrae il livello che il precedente ancora esponeva, e ogni generazione di team parte più in alto della precedente. Che mBaaS sia arrivato *prima* del BaaS generalista è la migliore curiosità della scala – il vincolo mobile (nessun team server, cicli di rilascio degli app store) ha forzato per prima l'astrazione più alta, e il resto del settore l'ha raggiunta dopo.

## La pizza, estesa a sette pioli

La classica analogia didattica (coniata dall'architetto software Albert Barron nel 2014) mappa il trio sulla cena: on-prem è cucinare a casa, IaaS è la pizza da infornare, PaaS è la consegna a domicilio, SaaS è la cena al ristorante. I pioli più recenti la estendono in modo naturale. **CaaS è affittare una cucina professionale con teglie standardizzate** – ricette proprie, impacchettate a modo proprio, cotte con l'attrezzatura altrui. **FaaS è pagare a fetta** – nessuna pizza esiste finché non viene fame, e non si paga mai per un tavolo vuoto. **BaaS è il kit pronto con tutto già fatto tranne il tocco che distingue** – impasto, salsa e forno sono risolti; si aggiunge il condimento che rende il ristorante quello che è. E **mBaaS è lo stesso kit in formato food truck**: il vincolo (il mobile) ha plasmato il kit per primo, e tutti gli altri l'hanno adottato dopo.

## IaaS vs. CaaS vs. PaaS vs. FaaS vs. BaaS vs. SaaS a confronto

| Dimensione | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- |
| Cosa si gestisce | Dal sistema operativo in su | Container + app | App + dati | Funzioni + dati | Logica personalizzata + dati | La configurazione |
| Unità di deployment | Macchina virtuale | Container | Applicazione | Funzione | Spesso niente (chiamate SDK) | – |
| Scalabilità | Si configura | La orchestra il provider | La piattaforma, per istanza | Automatica, fino a zero | Automatica dietro le API | Invisibile |
| Forma dei prezzi | Per ora-risorsa | Per nodo/container | Per istanza/piano | Per invocazione + tempo | Piano gratuito + piani | Per utente/mese |
| Tempo alla prima richiesta | Giorni | Ore | Ore | Minuti | **Minuti, con autenticazione e dati inclusi** | Immediato |
| Pressione di lock-in | Bassa | Bassa-media | Media | Media-alta | Alta – a meno che non sia open source | La più alta |
| Ideale per | Controllo totale, carichi speciali | Microservizi, stack poliglotti | App server su misura | Calcolo guidato dagli eventi | Backend applicativi standard | Consumare, non costruire |

### Le coppie che si confrontano davvero

**IaaS vs. PaaS** – "vogliamo gestire macchine o solo rilasciare un'app?". Scegliere IaaS solo quando il controllo è il requisito; altrimenti PaaS cancella il carico che va dal sistema operativo in su, a parità di applicazione.

**IaaS vs. CaaS** – la stessa domanda un livello più in alto: gestire la propria orchestrazione su macchine affittate, o affittare anche l'orchestrazione? A meno che gestire il control plane non sia la specialità di casa, CaaS.

**CaaS vs. PaaS** – l'unità che si consegna: container (qualsiasi stack, impacchettamento proprio, controllo a livello di orchestrazione) contro codice applicativo (runtime e convenzioni altrui, meno cerimoniale). Microservizi e parchi poliglotti pendono verso CaaS; una sola app standard pende verso PaaS.

**CaaS vs. FaaS** – persistenza contro eventi. I servizi di lunga durata con traffico tra servizi stanno nei container; il lavoro sporadico a forma di evento sta nelle funzioni che scalano a zero. Quasi tutti i sistemi reali fanno girare entrambi.

**PaaS vs. BaaS** – la confusione più profonda della scala, con [una voce dedicata](/glossary/it/paas-vs-baas/): PaaS ospita il backend *che bisogna comunque scrivere*; BaaS cancella quel passaggio per le funzionalità standard. Scrivere il backend, oppure averne uno.

**FaaS vs. BaaS** – il perimetro dell'esternalizzazione, sezionato in [BaaS vs. serverless](/glossary/it/baas-vs-serverless/): FaaS esternalizza il runtime del codice che si scrive; BaaS esternalizza il backend, così gran parte di quel codice non esiste mai. Le piattaforme BaaS mature incorporano FaaS, quindi in pratica i pioli si combinano.

**BaaS vs. mBaaS** – [storia contro presente](/glossary/it/mbaas-vs-baas/): stesso piolo, origine mobile-first. Se il prodotto vive di push, offline e stato del dispositivo, la *m* descrive ancora i requisiti; le piattaforme sono convergite comunque.

**SaaS vs. tutti gli altri** – il cambio di categoria: ogni altro modello è qualcosa su cui si costruisce; SaaS è qualcosa su cui *non* si costruisce niente. Se un carico di lavoro può essere SaaS, quello è quasi sempre il piolo sufficiente meno costoso – semplicemente smette di essere software proprio.

## Dove sta il "serverless"

Il serverless non è un ottavo piolo: è l'ombrello sopra i due pioli programmabili più alti. La [definizione canonica](https://martinfowler.com/articles/serverless.html) copre sia FaaS (codice proprio, eseguito su richiesta) sia BaaS (servizi backend pre-costruiti): in entrambi nessuno nel team gestisce un server, la capacità scala da sola e il costo segue il consumo. Quando qualcuno dice "siamo passati al serverless", la domanda da fare è *quale piolo*: funzioni scritte da loro, un backend che non hanno scritto o – nel caso più comune – la combinazione.

## Casi d'uso tipici

- **IaaS:** migrazioni lift-and-shift, runtime e hardware specializzati, regimi di conformità che esigono il controllo dell'infrastruttura.
- **CaaS:** flotte di microservizi, sistemi poliglotti, team che vogliono [orchestrazione di calibro Kubernetes](/glossary/it/kubernetes/) senza gestire il control plane.
- **PaaS:** applicazioni web e API su misura in cui la logica backend *è* il prodotto, mandate avanti da team che vogliono il deployment senza le operazioni sui server.
- **FaaS:** handler di webhook, job pianificati, pipeline di immagini e dati – lavoro guidato dagli eventi senza un backend completo attorno.
- **BaaS:** backend applicativi completi con esigenze standard – utenti, dati, file, notifiche – soprattutto per team frontend-first.
- **mBaaS:** lo stesso, in chiave mobile-first – prodotti costruiti su push, sync offline e stato per dispositivo.
- **SaaS:** tutto ciò che l'azienda usa ma non costruisce – il piolo che si consuma invece di architettarci sopra.

## Quale piolo scegliere? Matrice decisionale

```mermaid
flowchart TD
  accTitle: Scegliere un modello di servizio cloud in base a ciò che si distribuisce
  accDescr: Un flusso decisionale. Se qualcuno vende già il prodotto, si usa SaaS. Se invece si sta costruendo e le esigenze di backend sono standard, si usa BaaS, o mBaaS per i prodotti mobile-first. Se la logica backend è il prodotto, si usa PaaS per una sola app o CaaS per i microservizi. FaaS serve per il collante guidato dagli eventi su qualsiasi percorso, e IaaS solo quando il controllo dell'infrastruttura è esso stesso il requisito.
  Q0{"Il prodotto esiste<br/>già in commercio?"} -->|Sì| S["SaaS – consumarlo"]
  Q0 -->|No, stiamo costruendo| Q1{"Le esigenze di backend sono standard?<br/>(utenti, dati, file, push)"}
  Q1 -->|Sì| B["BaaS – mBaaS se mobile-first"]
  Q1 -->|"No – la logica backend È il prodotto"| Q2{"Una app o più servizi?"}
  Q2 -->|Una app| P["PaaS"]
  Q2 -->|Microservizi / poliglotta| C["CaaS"]
  Q1 -.->|Lavoro collaterale guidato dagli eventi| F["FaaS – su qualsiasi percorso"]
  Q2 -.->|Il controllo dell'infrastruttura è il requisito| I["IaaS"]
```

| Profilo | Piolo di partenza | Perché |
| --- | --- | --- |
| Team frontend o mobile che rilascia un prodotto | BaaS / mBaaS | Il backend standard esiste dal primo giorno; si scrive solo ciò che è unico |
| Team backend con un solo codebase server su misura | PaaS | Controllo totale del codice, nessuna macchina da gestire |
| Chi manda avanti un parco di microservizi o poliglotta | CaaS | Orchestrazione senza gestire il control plane |
| Chi automatizza eventi, collante e lavoro pianificato | FaaS | Si paga solo quando succede qualcosa |
| Chi fa girare sistemi legacy o hardware speciale | IaaS | Il controllo dei pioli bassi è il requisito |
| Chi risolve un problema che qualcuno ha già trasformato in prodotto | SaaS | Costruirlo è una distrazione |

Sopra a tutto questo si impilano due regole oneste: per impostazione predefinita si sceglie il piolo più alto che basta (ogni gradino in giù riassume lavoro operativo) e si rivaluta carico per carico – le aziende vivono su più pioli contemporaneamente, di proposito.

## Limiti e trade-off

- **IaaS:** il prezzo unitario lusinga; il personale ops che deve patchare, scalare e mettere in sicurezza è la fattura vera.
- **CaaS:** si è esternalizzato il control plane, non la complessità – immagini, manifest, service mesh e pipeline di deployment restano una disciplina di ingegneria.
- **PaaS:** si possiede comunque un'applicazione intera – ogni aggiornamento di dipendenza e ogni bug di autenticazione inclusi – più le convenzioni imposte dalla piattaforma.
- **FaaS:** cold start, limiti di esecuzione e un prezzo per invocazione che diventa ostile sotto carico pesante e costante.
- **BaaS / mBaaS:** un tetto alla personalizzazione per i requisiti molto fuori standard e il [lock-in](/glossary/it/vendor-lock-in-cloud/) più forte della scala *quando è proprietaria* – il motivo per cui le piattaforme basate su open source contano: tengono l'uscita reale.
- **SaaS:** dipendenza totale – roadmap, prezzi e portabilità dei dati vivono tutti nelle decisioni di qualcun altro.
- **Tutti quanti:** la linea della responsabilità condivisa si sposta, ma non va mai oltre i dati, la policy di accesso e il giudizio del cliente.

## La scala dei modelli di servizio 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. Occupa il piolo BaaS – completo in senso mBaaS, con push e SDK mobili di primo livello – e si copre deliberatamente in entrambe le direzioni. Verso l'alto: il backend standard arriva pre-costruito, quindi il primo giorno ha l'immediatezza di un SaaS per il prodotto di casa. Verso il basso: funzioni, trigger e job pianificati di [Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions) danno il piolo FaaS dentro la piattaforma, e la stessa azienda documenta il [piolo CaaS](https://blog.back4app.com/containers-as-a-service/) per i carichi che richiedono container. E poiché lo stack è open source, il peggior modo di fallire della scala – il lock-in in cima – arriva con una via di discesa documentata: ospitare in proprio lo stesso backend su qualsiasi piolo inferiore, senza riscritture.