Modelli di servizio cloud a confronto: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS e SaaS

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

Cosa significa “avviare il backend” a ogni piolo

# 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 / 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 — Back4app Flutter SDK
final order = ParseObject('Order')
  ..set('total', 129.9)
  ..set('status', 'paid');
await order.save(); // schema, API, auth, scaling handled below you

// 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")
  }
}

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

La definizione di cloud computing del NIST 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:

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.

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 – qualsiasi linguaggio, qualsiasi stack – e il provider gestisce lo scheduler, la rete tra i servizi e la macchineria della scalabilità, di solito 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 e dei parchi poliglotti che mal sopporterebbero le convenzioni di un PaaS.

La sottigliezza che separa CaaS da un tutorial su 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 seziona.

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, permessi, migrazioni, rate limiting – 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 – niente gira, e niente si paga, finché non succede qualcosa. I costi sono architetturali: cold start, 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.

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, l’archiviazione di file, le API generate automaticamente e le notifiche push arrivano pre-costruiti e gestiti, consumati dagli SDK client: 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 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, e la questione del lock-in – la debolezza onesta del piolo – dipende dal fatto che la piattaforma sia open source o proprietaria.

Ciò che BaaS elimina è l’infrastruttura e il boilerplate, non l’ingegneria: il modello di dati, le regole di sicurezza 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, SDK consapevoli del dispositivo e sincronizzazione offline 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.

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.

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

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

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

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 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 danno il piolo FaaS dentro la piattaforma, e la stessa azienda documenta il piolo CaaS 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.