BaaS open-source vs. BaaS proprietario gestito: quale scegliere?

Un BaaS open-source è una piattaforma backend con un core ospitabile in proprio; un BaaS proprietario gira solo su infrastruttura controllata dal provider. Entrambi vendono la stessa comodità: database gestito, autenticazione, archiviazione, API. La differenza è strutturale, non cosmetica: il software dietro quella comodità esiste indipendentemente dall’azienda che lo fa girare? È questa singola proprietà a decidere chi avrà potere contrattuale fra tre anni.

Punti chiave

Il test di portabilità, in codice

La comparazione si comprime in una domanda: a che cosa punta il codice? Con un core aperto punta a un motore che gira ovunque, e il deployment diventa un valore di configurazione:

// JavaScript / Node.js — Back4app JS SDK
// The openness test: this code runs unchanged on the managed platform
// or on a Parse Server you host yourself
Parse.initialize(APP_ID, JS_KEY);
Parse.serverURL = process.env.PARSE_SERVER_URL; // the only line that moves

const query = new Parse.Query('Invoice');
query.equalTo('status', 'overdue');
query.include('customer');
const overdue = await query.find(); // identical on either deployment

// Proprietary equivalent: rewrite the data layer before you can leave.

// Flutter / Dart — Back4app Flutter SDK
// The openness test: this code runs unchanged on the managed platform
// or on a Parse Server you host yourself
await Parse().initialize(
  appId,
  serverUrl, // the only value that moves between deployments
  clientKey: clientKey,
);

final query = QueryBuilder<ParseObject>(ParseObject('Invoice'))
  ..whereEqualTo('status', 'overdue')
  ..includeObject(['customer']);
final overdue = (await query.query()).results ?? [];

// Proprietary equivalent: rewrite the data layer before you can leave.

// iOS / Swift — Back4app Swift SDK
// The openness test: this code runs unchanged on the managed platform
// or on a Parse Server you host yourself
ParseSwift.initialize(
  applicationId: appId,
  clientKey: clientKey,
  serverURL: serverURL // the only value that moves between deployments
)

let query = Invoice.query("status" == "overdue")
  .include("customer")
let overdue = try await query.find() // identical on either deployment

// Proprietary equivalent: rewrite the data layer before you can leave.

// Android / Kotlin — Back4app Android SDK
// The openness test: this code runs unchanged on the managed platform
// or on a Parse Server you host yourself
Parse.initialize(
  Parse.Configuration.Builder(context)
    .applicationId(appId)
    .clientKey(clientKey)
    .server(serverUrl) // the only value that moves between deployments
    .build()
)

val query = ParseQuery.getQuery<ParseObject>("Invoice")
query.whereEqualTo("status", "overdue")
query.include("customer")
val overdue = query.find() // identical on either deployment

Con una piattaforma proprietaria la stessa query è scritta in API che non esistono da nessun’altra parte. Il codice funziona allo stesso modo giorno per giorno: la differenza affiora solo il giorno in cui si vuole andarsene, e a quel punto ha le dimensioni della codebase.

Il self-hosting è una proprietà strutturale

Il vendor lock-in di solito si discute come una sensazione: “siamo troppo dipendenti”. La divisione tra aperto e proprietario lo rende misurabile: il lock-in è il costo della migliore alternativa disponibile, e la possibilità di ospitare in proprio mette un tetto a quel costo.

Dal diagramma di sinistra discendono tre conseguenze:

• I prezzi restano onesti. Un provider i cui clienti possono andarsene verso la propria infrastruttura fissa i prezzi guardando a quell’alternativa. Un provider i cui clienti hanno davanti una riscrittura fissa i prezzi guardando alla riscrittura.
• La piattaforma è verificabile. I team di sicurezza possono leggere il sorgente del motore, seguire come vengono applicate le ACL e fissare versioni esatte: impossibile quando il backend è una scatola nera.
• La continuità è disaccoppiata dal provider. Le aziende vengono acquisite, cambiano rotta, dismettono prodotti. Un motore aperto sopravvive ai suoi provider; il progetto Parse Server ne è la prova canonica, mantenuto dalla comunità da oltre un decennio.

L’avvertenza onesta: un’opzione di uscita non è un’uscita gratuita. Esercitarla significa gestire in proprio server, database e backup – un progetto vero, trattato a fondo nella guida pratica alla migrazione tramite self-hosting (vedi i termini correlati). Il valore dell’opzione sta nell’esistere e nel limitare il rischio; il suo prezzo è che qualcuno deve essere in grado di esercitarla.

BaaS open-source vs. BaaS proprietario gestito

L’ultima riga merita enfasi: in un martedì qualunque le due cose sembrano identiche. Questa comparazione riguarda il rischio di coda e il potere contrattuale, ed è esattamente per questo che i team la sottovalutano finché non diventa costosa.

Casi d’uso tipici

• Startup che proteggono il proprio futuro. Scegliere un core aperto al giorno zero non costa nulla ed elimina il bivio “riscrivere o pagare” anni dopo, quando cambiare costa di più.
• Carichi di lavoro regolamentati e con sovranità dei dati. Team della sanità, della finanza e del settore pubblico che devono poter far girare lo stack in una giurisdizione precisa – o verificarlo riga per riga.
• Agenzie che consegnano progetti ai clienti. Consegnare su un motore aperto significa che il cliente possiede un backend eseguibile, non una dipendenza in abbonamento dalla piattaforma scelta dall’agenzia.
• Team già scottati. Chi è sopravvissuto alla chiusura di una piattaforma o a un prezzo moltiplicato per dieci tende a rendere il self-hosting un requisito vincolante la seconda volta.
• Anche il proprietario ha senso: prodotti profondamente integrati nell’ecosistema più ampio di un provider, o app di breve durata in cui un orizzonte di chiusura è accettabile e una specifica funzionalità chiusa fa risparmiare tempo vero.

Meglio un BaaS open-source o proprietario? Matrice decisionale

Se il fattore decisivo è “vogliamo la comodità del gestito e l’opzione di uscita”, non si tratta di un compromesso fra le colonne: è l’ibrido gestito su core aperto, ed è la scelta predefinita più solida per la maggior parte dei team. La questione adiacente costruire o comprare e il confronto con il PaaS seguono la stessa logica un livello più su.

Limiti e trade-off

• Open source non significa gestione gratuita. L’opzione di ospitare in proprio ha un prezzo: infrastruttura, aggiornamenti, backup e patch di sicurezza. Se nessuno nel team fosse in grado di esercitare l’uscita, il suo valore resta in parte teorico.
• Il ritardo sulle funzionalità è reale. In ambiti specifici i provider chiusi rilasciano funzionalità rifinite e ben integrate più in fretta dei progetti di comunità. Conviene valutare le funzionalità che servono davvero, non la filosofia.
• “Aperto” obbliga a leggere la licenza. L’apertura limitata agli SDK, le restrizioni delle licenze source-available e le funzionalità riservate alla versione ospitata annacquano la garanzia di uscita che questa categoria dovrebbe offrire.
• I livelli gestiti restano comunque diversi. Due provider che ospitano lo stesso motore aperto differiscono lo stesso per dashboard, comportamento in scalabilità e supporto: il motore mette un tetto al lock-in, ma non rende gli host intercambiabili nella pratica.
• Migrare non è mai solo configurazione. Anche con un core aperto, un’uscita vera comporta trasferimento dei dati, migrazione dei file, DNS e test di regressione. Il core aperto riduce il progetto da riscrittura a trasloco; non lo riduce a zero.

Il BaaS open-source 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. È la posizione ibrida che questo articolo sostiene: il motore sottostante è Parse Server – pubblico, verificabile, mantenuto dalla comunità – mentre Back4app lo fa girare con la rifinitura di una piattaforma proprietaria: provisioning, scalabilità, backup e monitoring inclusi. Le chiamate SDK e il Cloud Code puntano al motore aperto, quindi la porta d’uscita resta aperta per costruzione: si paga semplicemente qualcuno perché faccia girare lo stack finché conviene.