Cloud-native, IaaS, PaaS e SaaS, spiegati

Il cloud non è un posto nel cielo. È la domanda su quanta parte della macchina gestisci tu e quanta la gestisce qualcun altro.

Lavoro all'incrocio tra prodotto, GTM e AI come imprenditore del software. Nel momento in cui gli agenti AI girano dentro il tuo team di prodotto, questa domanda smette di essere teoria. Decide dove lavorano i tuoi agenti e quanto vanno veloci.

Cosa ti porti a casa:

• Cosa significano davvero IaaS, PaaS e SaaS, in una frase per livello.
• Perché i confini tra loro sono sfumati da tempo.
• Perché l'architettura cloud conta quando gli agenti girano da te.

La mia tesi: i tre modelli sono tre livelli dello stesso stack. Devi solo sapere quale gestisci tu.

🧨 Tre livelli, uno stack

La definizione ufficiale arriva dal NIST. Nel lavoro di ogni giorno bastano tre frasi semplici.

IaaS, Infrastructure as a Service. Il livello più basso. Affitti solo l'hardware: calcolo, storage, rete, virtualizzati in un data center. Il sistema operativo e tutto quello che ci sta sopra te lo installi tu. Affitti infrastruttura IT e manutenzione, niente altro.

PaaS, Platform as a Service. Il livello di mezzo. Qui non serve l'amministratore IT, serve lo sviluppatore. Il provider fornisce l'ambiente come framework e stabilisce linguaggi di programmazione, interfacce e archiviazione dei dati. Controlli solo il tuo codice e i tuoi dati, non l'infrastruttura sotto.

SaaS, Software as a Service. Il livello più alto, si appoggia sugli altri due. Il software non lo compri e non lo installi. Lo affitti come servizio. Di solito bastano un dispositivo connesso a internet e un browser. Hardware economico da te, potenza di calcolo piena nel data center.

Un'immagine quotidiana aiuta. IaaS è il capannone vuoto: affitti i muri e ti allestisci tutto da solo. PaaS è l'officina attrezzata: porti solo il tuo progetto. SaaS è l'elettrodomestico finito in abbonamento: lo accendi e lo usi.

🛠️ Perché i confini sfumano

La torta a strati pulita è teoria. Nella pratica i confini sfumano da anni. Già prima che Azure offrisse macchine virtuali nel 2012, spesso non era più chiaro dove finisse IaaS e cominciasse PaaS.

I progetti veri non chiedono quale modello. Mettono insieme capacità: un'API qui, un componente là, un servizio sopra. Non è IaaS o PaaS. È IaaS e PaaS e SaaS, spesso nello stesso progetto. In più c'è l'approccio ibrido, che sfuma anche il confine con l'hardware tuo on premises.

All'inizio il PaaS andava ancora spiegato e giustificato. Poco dopo si parlava solo di progetti di sviluppo veri. La maturità intorno al cloud ibrido è cresciuta anno dopo anno. È qui che siamo oggi: non un modello, ma un mix che assembli di proposito.

In più oggi ci sono intere categorie di prodotto che stanno tra i livelli. Database gestiti, servizi container, funzioni serverless. Tutti ibridi in cui il provider si prende più responsabilità che con l'infrastruttura grezza e detta meno regole di una piattaforma completa. Il modello a livelli resta comunque utile. Risponde all'unica domanda che conta: chi gestisce cosa.

🧭 Il percorso decisionale: un'azienda, tre risposte

Prendi un'azienda software B2B con 30 persone. Un prodotto, un team piccolo, nessun reparto ops proprio. È un buon caso di prova per la scelta, livello per livello.

L'infrastruttura grezza ha senso quando ti serve davvero il controllo. Mettiamo che i tuoi clienti stabiliscano per contratto dove stanno i dati e chi vi accede. Oppure che il tuo prodotto abbia requisiti di runtime o hardware che le piattaforme standard non coprono. Allora affitti le macchine e gestisci il resto da solo. Il prezzo: ti servono persone che sanno e vogliono farlo. Nell'azienda da 30 persone questo significa in fretta che 2 di loro non fanno altro che infrastruttura.

Una piattaforma ha senso quando il tuo collo di bottiglia è lo sviluppo, non le operations. Per la nostra azienda è il caso normale. Il team scrive codice, sotto la piattaforma si occupa di server, scaling e patch. Cedi controllo e ti riprendi velocità. Per un team di prodotto senza ops proprie è quasi sempre il punto di partenza giusto.

Il software finito ha senso per tutto quello che non ti differenzia. Mail, CRM, il sistema per i dati dei clienti, la contabilità, il tool di supporto: affitta, non costruire. L'azienda non conquista un solo cliente perché gestisce il ticketing in casa. Ogni ora spesa lì è un'ora non spesa sul prodotto.

Quindi il percorso decisionale non è una questione di fede. È una domanda per sistema: questo ci differenzia? Se no, compra il più in alto possibile nello stack. Se sì, prenditi tutto il controllo necessario e la minima gestione diretta possibile.

Per l'azienda da 30 persone il risultato spesso è questo: il prodotto su una piattaforma, il database come servizio gestito, un pezzo di infrastruttura grezza per l'unico cliente con requisiti speciali, una dozzina di tool affittati intorno. Esattamente il mix della sezione precedente. Non una regola di purezza, ma una serie di singole decisioni consapevoli.

⚖️ Tre trade-off, in parole semplici

Dietro ogni scelta di livello ci sono gli stessi 3 trade-off. Conoscili e collochi qualsiasi slide di un vendor in pochi minuti.

Controllo contro responsabilità. Ogni livello che gestisci tu ti obbedisce. E ti chiama quando si rompe di notte. Il controllo suona come libertà, in pratica è reperibilità. La domanda onesta non è "vogliamo il controllo" ma "vogliamo la responsabilità che ci viene dietro".

Lock-in contro velocità. Più servizi pronti usi, più veloce rilasci. E più ti radichi in un solo provider. Cambiare diventa caro, non impossibile. L'errore non è il lock-in in sé. L'errore è prenderselo senza accorgersene. Costruisci tutto da solo per paura del lock-in e paghi il prezzo adesso invece che forse più avanti.

Costi fissi contro costi a consumo. Gestire in casa costa soldi che qualcuno usi il tuo prodotto o no. I servizi a consumo costano poco sotto carico basso e crescono con il tuo successo. Per un prodotto giovane di solito è meglio la seconda. Paghi tanto solo quando hai clienti. In cambio devi tenere d'occhio la fattura, perché i costi a consumo crescono in silenzio.

L'ordine conta: prima decidi cosa ti differenzia, poi pesa i trade-off sistema per sistema. Fallo al contrario e discuterai di vendor per settimane, restando comunque senza una linea.

🤖 Perché conta nell'era degli agenti

È qui che per me diventa concreto. Costruisco team di prodotto AI-native. Lo chiamo Get Multiplayer: come persone e agenti AI lavorano insieme. Un hyperlean team, pochi professionisti più agenti che girano 24 ore su 24. Tre invece di trenta.

Questi agenti girano da qualche parte. Che sia su IaaS, su PaaS o collegati come SaaS decide latenza, costi e controllo dei dati. Se devi tenere codice, Jira e dati nell'UE, la scelta del livello non è una domanda tecnica ma di compliance.

Per le aziende DACH non è una nota a piè di pagina. Molti clienti B2B richiedono per contratto che i dati restino nell'UE o in Svizzera. È il caso normale, non l'eccezione. Tutti e 3 i livelli sono disponibili con regioni europee. Devi solo verificarlo al momento della scelta invece di ripararlo dopo.

In più c'è il contesto. Un agente vale quanto le sue fondamenta. Quelle fondamenta sono il Context Engine: il contesto di business e di codice della tua azienda. Dove vive quel contesto e come lo raggiungono gli agenti è una questione di architettura cloud. Senza un contesto pulito è garbage in, garbage out.

🧑‍💻 Cosa significa per un piccolo team di prodotto?

Compra come servizio finito tutto quello che non ti differenzia. Gestisci in casa il meno possibile. E decidi la questione dei livelli prima che i tuoi agenti girino, non dopo. Perché è l'architettura a stabilire cosa possono raggiungere i tuoi agenti e quanto in fretta.

Questo si riallaccia al punto sopra. Quando gli assistenti AI lavorano dentro il prodotto, ogni decisione di livello conta doppio. Stabilisce dove gira il tuo codice. E stabilisce se un agente può raggiungere log, dati e deployment senza che un umano clicchi in mezzo.

Un team piccolo qui ha un vantaggio: poco legacy. Puoi tagliare l'architettura in modo che il contesto stia in un posto solo e gli agenti lavorino lì. Come si mette insieme un setup del genere nella pratica lo mostro in prodotto SaaS in 90 giorni e in Da Vibe Coding ad Agentic Engineering.

La questione dei livelli fa parte del product management, non dell'IT. Raccolgo altro su questo nell'hub software product management.

🎢 Alti, bassi, avvertenza

✅ Cosa funziona: i livelli come modello mentale. Per ogni servizio chiediti: quale livello gestisco io, quale lo gestisce qualcun altro. Così sparisce gran parte della confusione.

❌ Cosa non funziona: trattare i modelli come scatole rigide. La realtà è mista, ibrida e sfumata. Se aspetti la torta pulita, pianifichi fuori dalla pratica.

⚠️ Attenzione: non lasciare che la tua architettura cloud nasca per caso. Nel momento in cui gli agenti girano da te, decide velocità, costi e dove stanno i tuoi dati.

Il cloud non è un posto nel cielo, è una decisione su cosa gestisci tu. Nell'era degli agenti quella decisione diventa più importante, non meno. Se vuoi mettere nel tuo team di prodotto agenti che conoscono il tuo contesto, dai un'occhiata a teklens.ai.