--- term: 'PaaS vs. BaaS' seoTitle: 'Che cos''è PaaS? Platform-as-a-Service vs. BaaS' headline: 'Che cos''è PaaS (Platform-as-a-Service)?' slug: paas-vs-baas category: cloud-architecture shortDefinition: 'PaaS è un modello cloud in cui il provider gestisce la piattaforma su cui viene distribuito il codice, mentre l''applicazione resta da scrivere e mantenere.' relatedTerms: - baas-vs-custom-backend - infrastructure-as-a-service - serverless-architecture - cloud-vendor-lock-in - baas-vs-serverless contrastsWith: - infrastructure-as-a-service aboutTerms: - 'Platform-as-a-Service (PaaS)' - 'Backend-as-a-Service (BaaS)' faq: - question: 'Che cos''è PaaS, in parole semplici?' answer: 'PaaS significa affittare la piattaforma invece delle macchine. Il provider possiede i server, il sistema operativo, il runtime e gli strumenti di deployment; si spinge il codice dell''applicazione e la piattaforma lo compila, lo esegue e lo tiene online. L''intera applicazione resta comunque da scrivere e mantenere: la piattaforma toglie solo il lavoro sull''infrastruttura sottostante.' - question: 'Qual è la differenza tra IaaS, PaaS e SaaS?' answer: 'Sono gradini di una scala di astrazione definita da chi gestisce cosa. IaaS affitta infrastruttura grezza – macchine virtuali, archiviazione, rete – e tutto ciò che sta dal sistema operativo in su è a carico del cliente. PaaS affitta una piattaforma gestita: basta portare codice applicativo e dati. SaaS è il piolo più alto: un''applicazione finita, pronta all''uso. Ogni gradino in più scambia controllo con velocità.' - question: 'Qual è la differenza tra PaaS e BaaS?' answer: 'PaaS dà un posto dove far girare il backend che bisogna comunque scrivere; BaaS dà il backend stesso. Su un PaaS si scrive l''applicazione server – rotte, autenticazione, collegamento al database – e la piattaforma la ospita. Su un BaaS le funzionalità standard come autenticazione, CRUD sul database e archiviazione di file sono pre-costruite e si consumano dagli SDK client, quindi nei casi comuni non c''è alcuna applicazione server da scrivere.' - question: 'PaaS è la stessa cosa di serverless?' answer: 'No. Un''applicazione su PaaS gira di solito in modo continuo su istanze che si configurano e si pagano, e scala solo come è stato configurato. Il calcolo serverless viene fornito a evento: le funzioni si avviano su richiesta, si pagano per invocazione e tempo di esecuzione, scalano a zero quando sono a riposo e possono pagare una penalità di cold start sulla prima richiesta. PaaS riguarda l''hosting di un''app sempre accesa; serverless riguarda l''esecuzione di codice solo quando succede qualcosa.' - question: 'Kubernetes o Docker sono un PaaS?' answer: 'No: sono mattoni open source, non piattaforme. Docker impacchetta le applicazioni in container; Kubernetes orchestra i container su più macchine. Un PaaS può essere costruito sopra di loro e nasconderne la complessità dietro un comando di deployment. Se il team gestisce Kubernetes direttamente, siamo più vicini a IaaS con strumenti migliori che a PaaS.' - question: 'Quali sono gli svantaggi di PaaS?' answer: 'Gli inconvenienti più citati sono il vendor lock-in (le app scritte contro servizi specifici della piattaforma costano care da spostare), il minor controllo su runtime e sistema operativo, prezzi che possono salire ripidamente a scala costante, la dipendenza dall''uptime e dalle scelte di prodotto del provider e i vincoli di conformità quando le normative richiedono il controllo dell''infrastruttura. Scegliere piattaforme basate su standard aperti o su open source attenua quasi tutti questi punti.' - question: 'Come si pagano i servizi PaaS?' answer: 'Di norma per istanza in esecuzione o per fascia di risorse, con fatturazione mensile o oraria: si paga la capacità che tiene online l''applicazione, che arrivi traffico oppure no. Il costo è prevedibile ma mai nullo. Si contrappone ai prezzi serverless per invocazione, che scendono a zero a riposo, e ai piani BaaS, che di solito includono richieste, archiviazione e utenti in un piano gratuito più fasce fisse al di sopra.' - question: 'A chi conviene PaaS?' answer: 'Ai team che vogliono scrivere e possedere un''applicazione server su misura senza gestire infrastruttura: team di prodotto che rilasciano API web, aziende che standardizzano il deployment su molti servizi e sviluppatori che hanno bisogno del controllo pieno sulla logica backend ma di nessuna gestione dei server. Se le esigenze di backend sono perlopiù standard – utenti, dati, archiviazione – un BaaS elimina anche il passaggio di scrivere l''applicazione, ed è di solito la strada più rapida.' 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: 'Platform as a service (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Platform_as_a_service' - name: 'The Twelve-Factor App methodology' url: 'https://12factor.net' - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)' url: 'https://martinfowler.com/articles/serverless.html' cta: title: 'Salta la piattaforma, parti da un backend finito' text: 'Back4app offre ciò che un PaaS chiede ancora di costruire: database, autenticazione, archiviazione di file e API arrivano già pronti, con le funzioni Cloud Code per la logica personalizzata. Da zero a un backend funzionante in pochi minuti, gratis.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-30' translationKey: paas-vs-baas --- **PaaS è un modello cloud in cui il provider gestisce la piattaforma su cui viene distribuito il codice, mentre l'applicazione resta da scrivere e mantenere.** In parole povere: si affitta la piattaforma, ma l'app resta propria. La [definizione del NIST](https://csrc.nist.gov/pubs/sp/800/145/final) traccia la linea con precisione – il provider controlla server, sistemi operativi e runtime; il cliente controlla l'applicazione distribuita e i suoi dati. ## Punti chiave | Domanda | Risposta | | --- | --- | | Che cos'è | Una piattaforma gestita che compila, esegue e scala il codice applicativo che le viene spinto | | Cosa resta da fare | Scrivere e mantenere l'intera applicazione server | | Il problema che risolve | Provisioning dei server, patch del sistema operativo, impiantistica del deployment | | Modello di fatturazione | Per istanza o fascia – la capacità resta accesa, che arrivi traffico o no | | vs. BaaS | PaaS ospita il backend che si scrive; BaaS consegna il backend già pronto | ## Che aspetto ha l'uso di un PaaS L'esperienza PaaS per eccellenza è il deployment con un solo comando e senza configurare infrastruttura: ```bash # Il flusso PaaS tipico: si spinge il codice, la piattaforma fa il resto $ git push platform main -----> Runtime detected: Node.js -----> Installing dependencies, building release -----> Launching web process (2 instances) https://my-api.example.app deployed ``` Quello che il comando distribuisce, però, resta un'applicazione server completa scritta in casa: routing, validazione, collegamento al database, gestione dell'autenticazione. ```javascript // server.js – su un PaaS tutto questo resta da scrivere e mantenere const app = express(); app.get('/tasks', async (req, res) => { const user = await authenticate(req); // fatto in casa const tasks = await db.query( // anche questo 'SELECT * FROM tasks WHERE owner = $1 AND done = false', [user.id] ); res.json(tasks); // e anche questo }); app.listen(process.env.PORT); ``` È lo scambio essenziale di PaaS: l'infrastruttura sparisce, ma l'applicazione backend – e ogni patch di sicurezza, aggiornamento di dipendenza ed endpoint che contiene – resta codice di casa. ## La scala dell'astrazione Ogni modello di servizio cloud risponde a una sola domanda: quanto si affitta e quanto si continua a gestire? ```mermaid flowchart LR accTitle: La scala dell'astrazione cloud accDescr: Cinque gradini, dall'on-premises attraverso IaaS, PaaS e BaaS fino a SaaS, dove ogni piolo affitta una parte più grande dello stack – prima le macchine, poi la piattaforma, poi il backend, poi l'applicazione finita. A["On-premises
si gestisce tutto"] --> B["IaaS
affittare le macchine"] B --> C["PaaS
affittare la piattaforma"] C --> D["BaaS
affittare il backend"] D --> E["SaaS
affittare l'app finita"] ``` La divisione delle responsabilità, livello per livello: | Livello | On-prem | IaaS | PaaS | BaaS | SaaS | | --- | --- | --- | --- | --- | --- | | Codice applicativo | Cliente | Cliente | Cliente | Solo la logica personalizzata | Provider | | Funzionalità backend (auth, CRUD, archiviazione) | Cliente | Cliente | Cliente | Provider | Provider | | Runtime e middleware | Cliente | Cliente | Provider | Provider | Provider | | Sistema operativo e patch | Cliente | Cliente | Provider | Provider | Provider | | Server, archiviazione e rete | Cliente | Provider | Provider | Provider | Provider | Esistono varianti specializzate di PaaS per compiti più ristretti – piattaforme di integrazione, piattaforme mobili, piattaforme di database, piattaforme di comunicazione – ma stanno tutte sullo stesso piolo: un posto gestito dove far girare o collegare il software che si costruisce. ## PaaS vs. BaaS: la differenza pratica BaaS è il piolo successivo, e la differenza si vede in ciò che *non* si scrive. L'endpoint della lista di attività qui sopra – controllo dell'autenticazione, query, risposta – su un BaaS viene sostituito da una chiamata SDK diretta da qualsiasi client, con il controllo degli accessi applicato dalla piattaforma: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK const query = new Parse.Query('Task'); query.equalTo('done', false); query.descending('createdAt'); const tasks = await query.find(); console.log(`${tasks.length} open tasks`); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK final query = QueryBuilder(ParseObject('Task')) ..whereEqualTo('done', false) ..orderByDescending('createdAt'); final response = await query.query(); if (response.success) { print('${response.results?.length} open tasks'); } ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK let query = Task.query("done" == false) .order([.descending("createdAt")]) query.find { result in switch result { case .success(let tasks): print("\(tasks.count) open tasks") case .failure(let error): print(error.localizedDescription) } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK val query = ParseQuery.getQuery("Task") query.whereEqualTo("done", false) query.orderByDescending("createdAt") query.findInBackground { tasks, e -> if (e == null) { Log.d("Tasks", "${tasks.size} open tasks") } } ``` | Dimensione | PaaS | BaaS | | --- | --- | --- | | Cosa gestisce il provider | La piattaforma sotto l'app | La piattaforma *e* le funzionalità di backend | | Cosa si scrive | L'intera applicazione server | Solo la logica personalizzata, come funzioni | | Unità di deployment | Un'applicazione | Spesso niente – i client chiamano gli SDK | | Autenticazione, database, archiviazione, API | Codice proprio, infrastruttura altrui | Pre-costruiti, esposti tramite SDK | | Scalabilità | Configurata per istanza o fascia | Automatica dietro API gestite | | Ideale per | App server su misura che si vogliono possedere | Backend standard che si preferisce non scrivere | ## PaaS vs. serverless I due modelli sono cugini, non sinonimi. Un'app su PaaS gira in continuazione su capacità configurata; il calcolo serverless si materializza a evento, [si paga per invocazione e scala a zero](https://martinfowler.com/articles/serverless.html), al prezzo di cold start e limiti di esecuzione. Nella pratica il confine si sfuma: le piattaforme moderne innestano funzioni serverless su un hosting in stile PaaS, e un'[architettura serverless](/glossary/it/architettura-serverless/) può servire un'intera API che un PaaS avrebbe ospitato come una sola app. La decisione dipende dalla forma del traffico: un carico costante favorisce un processo PaaS sempre acceso, mentre un carico a picchi o quasi sempre inattivo favorisce il calcolo per invocazione. ## Casi d'uso tipici - **API e servizi web su misura.** Un backend con logica troppo specifica per le funzionalità pre-costruite – motori di prezzi, marketplace, strumenti interni – distribuito senza possedere server. - **Standardizzare molti deployment.** I team che fanno girare decine di servizi adottano un PaaS perché ogni servizio venga compilato, distribuito, tracciato e scalato allo stesso modo. - **Migrare da server gestiti in proprio.** Le applicazioni server esistenti (soprattutto le app [twelve-factor](https://12factor.net)) passano a un PaaS quasi senza modifiche: stesso codice, niente più patch del sistema operativo. - **Dove BaaS sostituisce PaaS: i backend applicativi standard.** Se il backend è utenti + dati + file + notifiche, le funzionalità pre-costruite eliminano proprio quel livello applicativo che un PaaS ospiterebbe – il caso comune dei prodotti mobile e web. - **Ibrido: nucleo su misura in stile PaaS, BaaS per il resto.** Alcuni team tengono un singolo servizio su misura su una piattaforma, mentre gestione utenti, API sui dati e archiviazione arrivano da un BaaS affiancato. ## Scegliere PaaS o BaaS? Matrice decisionale | Pendere verso PaaS quando… | Pendere verso BaaS quando… | | --- | --- | | Il backend *è* il prodotto, logica su misura ovunque | Il backend è impiantistica standard attorno al prodotto | | Esiste già un codebase server da ospitare | Si parte da zero e si vuole evitare quel codebase | | Serve un linguaggio, un framework o un protocollo qualsiasi | Le piattaforme coperte dagli SDK (web, mobile) sono gli obiettivi | | Un team backend possiede l'applicazione server | Il team è orientato a frontend e mobile | | I prezzi per istanza si adattano a un traffico costante | Un piano gratuito e la scalabilità gestita si adattano a un MVP o a un carico a picchi | Se quasi tutti i requisiti sono standard e solo qualcuno è su misura, non è un motivo per scegliere PaaS: un BaaS con un runtime per funzioni integrato copre entrambi i lati con meno codice da possedere. ## Limiti e trade-off - **Resta comunque un'applicazione da possedere.** Aggiornamenti del framework, patch di sicurezza nelle dipendenze, bug nell'autenticazione: un PaaS ospita il backend, non lo mantiene. È il costo che BaaS rimuove e PaaS no. - **Vendor lock-in.** Le app scritte contro servizi e formati di deployment specifici di una piattaforma costano care da spostare. Le contromisure: restare su standard aperti, containerizzare, preferire piattaforme costruite su open source – la stessa cautela sul vendor lock-in vale su e giù per la scala. - **Costo a scala costante.** La comodità del gestito porta con sé un margine; i carichi grandi e stabili alla fine costano meno sui pioli più bassi della scala, al prezzo di riassumere il carico operativo. - **Controllo ridotto.** Nessun accesso al sistema operativo, messa a punto della rete limitata e versioni del runtime sui tempi del provider. I regimi di conformità che richiedono il controllo dell'infrastruttura possono escludere il modello. - **Dipendenza dal provider.** Disservizi, cambi di prezzo e dismissioni arrivano secondo i tempi del provider, non quelli di chi costruisce. Il curriculum del provider va giudicato come parte dell'architettura. ## PaaS vs. BaaS 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. Questo la colloca un piolo sopra PaaS: ogni app parte con il backend completo già pronto. Il vuoto sulla logica personalizzata, che altrimenti riporterebbe giù a un PaaS, è coperto da **[Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions)**: funzioni serverless, trigger e job pianificati. E poiché lo stack è open source, l'obiezione sul lock-in si ribalta: lo stesso backend si può ospitare in proprio su qualsiasi infrastruttura, quindi scendere la scala in un secondo momento resta possibile senza riscritture.