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

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

Che aspetto ha l’uso di un PaaS

L’esperienza PaaS per eccellenza è il deployment con un solo comando e senza configurare infrastruttura:

# 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.

// server.js – su un PaaS tutto questo resta da scrivere e mantenere
import express from 'express';
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?

La divisione delle responsabilità, livello per livello:

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 / 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 — Back4app Flutter SDK
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false)
  ..orderByDescending('createdAt');
final response = await query.query();
if (response.success) {
  print('${response.results?.length} open tasks');
}

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

// Android / Kotlin — Back4app Android SDK
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("done", false)
query.orderByDescending("createdAt")
query.findInBackground { tasks, e ->
  if (e == null) {
    Log.d("Tasks", "${tasks.size} open tasks")
  }
}

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, 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 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) 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

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