Sviluppare una piattaforma SaaS multi-tenant: le decisioni architetturali che contano

La multi-tenancy non è una funzionalità da aggiungere quando arrivano i clienti: è un'architettura su cui impegnarsi fin dal primo giorno, oppure da pagare a caro prezzo più avanti. Le decisioni che prendete su isolamento, dati e fatturazione condizionano tutto ciò che segue.

Una piattaforma multi-tenant serve molti clienti (tenant) da un'unica applicazione e infrastruttura, mantenendo isolati i dati e l'esperienza di ciascun tenant. Se ben realizzata, è invisibile agli utenti ed efficiente da gestire. Se realizzata male, espone dati, rallenta e diventa impossibile da modificare in sicurezza.

La scelta centrale riguarda il modo in cui isolate i dati dei tenant: un database condiviso con un identificativo del tenant su ogni riga, uno schema per tenant oppure un database per tenant. Il database condiviso con identificativo del tenant è la soluzione che scala meglio e costa meno, ma richiede un controllo rigoroso su ogni query. Un database per tenant offre l'isolamento più forte ed è talvolta richiesto per ragioni di conformità, a fronte di costi operativi più elevati. La maggior parte dei SaaS B2B parte con un isolamento condiviso e una delimitazione dei tenant rigorosa e sistematicamente imposta.

Fatturazione degli abbonamenti, piani, licenze per utente, misurazione dei consumi e diritti di accesso non sono un'integrazione da aggiungere in un secondo momento: toccano il modello dati, le autorizzazioni e la superficie del prodotto. Decidere presto come i piani si traducono in funzionalità (entitlement) vi evita di disperdere in seguito la logica dei prezzi in tutto il codice.

• Delimitazione dei tenant imposta a livello di dati, non solo nell'interfaccia.
• Autenticazione, ruoli e autorizzazioni pensati per i team, non per singoli utenti.
• Un modello di entitlement che colleghi in modo pulito i piani alle funzionalità.
• Osservabilità per singolo tenant, per poter vedere e diagnosticare l'esperienza di un cliente specifico.

Con fondamenta solide, la crescita è un problema di scalabilità. Con fondamenta sbagliate, la crescita significa riscrivere tutto, di solito nel momento peggiore possibile: proprio quando arrivano i clienti.