Cos'è il PaaS? Platform as a Service a confronto con IaaS, SaaS e Kubernetes

Il Platform as a Service (PaaS) è un modello cloud in cui fornisci la tua applicazione, come codice sorgente o immagine container, e il provider la esegue. La piattaforma ne fa la build e il deploy, ne gestisce la scalabilità e si occupa dei server, dei sistemi operativi e delle reti sottostanti. Tu resti responsabile dell'applicazione, della sua configurazione e dei suoi dati.

La definizione più citata viene dal National Institute of Standards and Technology statunitense (NIST SP 800-145). Con un PaaS fai il deploy delle tue applicazioni sull'infrastruttura del provider, ma non gestisci né controlli l'infrastruttura cloud sottostante, compresi rete, server, sistemi operativi e storage (nell'originale: “not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage”). Controlli invece le applicazioni di cui hai fatto il deploy e, se previsto, le impostazioni dell'ambiente di hosting.

Cosa fa un PaaS al posto tuo

L'elenco esatto varia da provider a provider, ma un PaaS completo copre quasi tutto questo:

• Build: trasforma un repository Git in un'immagine eseguibile, con buildpack che riconoscono il tuo linguaggio oppure a partire da un Dockerfile che aggiungi al repository.
• Deploy: distribuisce le nuove release, spesso a ogni push su un branch, e tiene uno storico di cosa è girato e quando.
• Scalabilità: più repliche o una taglia più grande sono un'impostazione, non un nuovo server da installare.
• TLS e domini: ogni app riceve un hostname, e i certificati per i tuoi domini vengono emessi e rinnovati per te.
• Log e metriche: log di runtime e grafici di CPU e memoria senza dover gestire un tuo stack di logging.
• Database gestiti: PostgreSQL, MySQL o una cache accanto all'app, con repliche e backup come opzioni.
• Server e sistemi operativi: patch degli host, sostituzione dell'hardware guasto e rete sempre attiva.

Cosa resta a te

Un PaaS elimina il lavoro sull'infrastruttura, non la responsabilità per il tuo prodotto. Restano a te:

• Il tuo codice e le sue dipendenze, compreso l'aggiornamento delle librerie quando esce una vulnerabilità.
• Configurazione e secret: variabili d'ambiente, chiavi API e chi nel tuo team può vederle.
• I tuoi dati: lo schema, le migrazioni, l'attivazione dei backup e la prova di un ripristino.
• Dimensionamento e costi: quante repliche esegui e con quale piano, e la fattura che ne deriva.
• Sicurezza dell'applicazione: autenticazione, validazione degli input e accesso alla dashboard.
• Posizione: in quale regione girano la tua app e i suoi dati.

PaaS vs IaaS vs SaaS vs serverless vs Kubernetes

I modelli si differenziano per ciò che fornisci e ciò che gestisci. Ecco un confronto di massima:

Modello	Cosa porti tu	Cosa gestisce il provider	Cosa gestisci ancora tu	Uso tipico
IaaS	Macchine virtuali, dischi, reti	Hardware, virtualizzazione, data center	Sistema operativo, runtime, deploy, scalabilità, patch	Pieno controllo, software legacy o particolare
PaaS	Codice sorgente o un'immagine container	Server, sistema operativo, build, deploy, routing, spesso database	Applicazione, configurazione, dati	Web app, API, worker
SaaS	Nessun deploy	L'intera applicazione	Impostazioni, utenti e i tuoi dati nell'app	Software aziendale standard
Serverless (FaaS)	Funzioni	Esecuzione per evento o richiesta, scalabilità in base alla domanda	Codice delle funzioni, cold start, limiti di tempo e dimensione	Carichi event-driven e a picchi
Kubernetes	Immagini container e manifest	Come servizio gestito: il control plane	Nodi, deployment, ingress, configurazione dello scaling, CI/CD, logging	Grandi setup con un platform team

Con l'IaaS ricevi macchine virtuali e il resto è a carico tuo. Il NIST lo descrive come la fornitura di “processing, storage, networks, and other fundamental computing resources” (capacità di calcolo, storage, reti e altre risorse informatiche fondamentali) su cui esegui software arbitrario, compreso il sistema operativo.

Il SaaS è l'estremo opposto: usi l'applicazione finita del provider nel browser o tramite API e non fai il deploy di nulla.

Il serverless, inteso come funzioni, esegue il tuo codice in piccole funzioni attivate da eventi o richieste HTTP e fattura in base all'uso effettivo. Il whitepaper sul serverless della CNCF osserva che la maggior parte dei runtime limita la dimensione o il tempo di esecuzione di ogni funzione e che l'avvio dopo periodi di inattività può essere lento. Un PaaS invece di solito esegue la tua app come processo sempre attivo.

Kubernetes è un orchestratore di container, e la sua documentazione ufficiale dice che Kubernetes “is not a traditional, all-inclusive PaaS”, cioè non è un PaaS tradizionale e onnicomprensivo. Non fa il deploy di codice sorgente, non fa la build della tua applicazione e non include database come servizi integrati. Fornisce i mattoni per costruire piattaforme. Per un confronto più approfondito leggi PaaS vs Kubernetes.

Quando un PaaS è la scelta giusta

• Sviluppi web app, API o background worker in un linguaggio diffuso.
• Nel tuo team nessuno ha il compito di gestire server o cluster, e per ora preferisci non assumere qualcuno per farlo.
• Vuoi una nuova versione online pochi minuti dopo un merge, con log e metriche già pronti.
• Ti servono database, storage e app in un unico posto, con un'unica fattura.

Quando non lo è

• Ti serve un kernel personalizzato, hardware speciale o un controllo di basso livello sulla rete. Una macchina virtuale o il bare metal sono più adatti.
• Il tuo software si aspetta l'accesso root, un init system completo o pacchetti installati con script del maintainer. Un Dockerfile può coprire parte di queste esigenze; certi software girano bene solo su una VM.
• Hai carichi di lavoro grandi e costanti e hai già un platform team. A quel punto gestire un'infrastruttura tua può convenire.
• Il tuo codice gira pochi secondi al giorno in risposta a eventi. Una piattaforma di funzioni può costare meno.
• Hai un requisito legale o di compliance che le regioni o le certificazioni del provider non possono soddisfare.

Come valutare un PaaS

Regioni e posizione dei dati

Verifica dove girano davvero l'app, il database, i backup e i log, e se puoi sceglierlo per ogni servizio. Controlla anche dove si trovano il control plane del provider e i dati dell'account, e in quale paese ha sede l'azienda. Per i dati personali di persone nell'UE contano entrambe le domande.

Servizi inclusi

Guarda cosa è incluso nella piattaforma e cosa richiede un fornitore terzo: database, object storage, email, CDN, log e metriche, ambienti di anteprima. Ogni componente aggiuntivo di un altro fornitore è un contratto in più, una fattura in più e un sub-responsabile del trattamento in più.

Modello di prezzo

Le piattaforme fatturano per istanza, per secondo di esecuzione, per richiesta o per utente, e alcune misurano in aggiunta banda, minuti di build o volume dei log. Stima un mese con i tuoi numeri reali, compresi il database e un secondo ambiente per lo staging.

Portabilità

Il lock-in di solito si nasconde nella build e nella configurazione, non nel codice. Preferisci una piattaforma che costruisce immagini container standard da un Dockerfile o dai Cloud Native Buildpacks: il lifecycle dei buildpack esporta un'immagine OCI, lo stesso formato eseguito dalle altre piattaforme container. Tieni la configurazione nelle variabili d'ambiente e usa motori di database standard di cui puoi fare il dump e il ripristino altrove. Così cambiare piattaforma richiede una migrazione, non una riscrittura.

Dove si colloca Nodion

Nodion è un PaaS gestito da Nodion GmbH, con sede a Stoccarda, in Germania. Fai il deploy da Git con un Dockerfile o con i Cloud Native Buildpacks di Nodion, oppure da un'immagine già pronta. Ogni app riceve processi, log, metriche e domini, le app Git possono aprire ambienti di anteprima, e Postgres, MySQL, Valkey e ClickHouse gestiti si collegano dalla scheda Environment dell'app. Scegli la regione per ogni servizio, per esempio EU Central a Francoforte. I dettagli sono su Applications.