Piattaforma multi-tenant: cos'è e come separa i dati dei clienti

Una piattaforma multi-tenant è un unico software usato da più aziende clienti, chiamate tenant (letteralmente «inquilini»), ognuna con i suoi dati, i suoi utenti e le sue impostazioni, invisibili agli altri. È come un condominio: la struttura è una, gli appartamenti sono separati. Il vantaggio è che il software si sviluppa, si aggiorna e si mantiene una volta sola per tutti; la responsabilità è garantire che i dati di un cliente non finiscano mai davanti a un altro.

Che differenza c'è tra multi-tenant e una copia del software per ogni cliente?

Le strade per servire più clienti con lo stesso software sono due:

• una copia per cliente (single-tenant): ogni azienda ha la sua installazione, con il suo database e il suo server. È semplice da capire, ma ogni aggiornamento va ripetuto per ogni copia, e con dieci o cento clienti diventa un lavoro enorme;
• una piattaforma per tutti (multi-tenant): un'unica applicazione serve tutti i clienti, che restano separati a livello di dati e permessi. Gli aggiornamenti si fanno una volta, i costi di gestione crescono molto più lentamente del numero di clienti.

Quasi tutti i software in abbonamento che usiamo ogni giorno sono multi-tenant. Anche ROOMIO, il gestionale per strutture ricettive che ho sviluppato, serve più strutture con la stessa piattaforma, e permette di gestire più strutture da un account con accessi separati per i collaboratori.

Come si separano i dati dei clienti?

È la scelta tecnica più importante, e va fatta all'inizio. I modelli principali sono tre:

1. database condiviso, con ogni riga etichettata con il cliente a cui appartiene. È il modello più efficiente, ma richiede che ogni lettura e ogni scrittura filtri per cliente, senza eccezioni;
2. schemi separati nello stesso database: ogni cliente ha le sue tabelle. La separazione è più netta, ma aggiornare la struttura del database richiede di farlo per ogni schema;
3. database dedicati per cliente: massima separazione, utile per clienti con requisiti particolari, ma con costi e complessità più alti.

Molte piattaforme usano un modello misto: database condiviso per la maggior parte dei clienti, database dedicato per quelli che lo richiedono per contratto.

Come si evita che un cliente veda i dati di un altro?

Nel modello con database condiviso, il rischio è un errore nel codice: una ricerca scritta senza il filtro del cliente, e i dati di un'azienda compaiono a un'altra. È il tipo di errore più grave che una piattaforma possa avere.

Per questo non mi affido solo all'attenzione di chi scrive il codice. Le difese che uso sono a più livelli:

• regole nel database stesso, che impediscono di leggere righe di un altro cliente anche se il codice dimentica il filtro (in PostgreSQL si chiama row level security);
• il cliente stabilito una volta all'inizio di ogni richiesta, in base all'utente autenticato, e mai preso da un parametro che l'utente può modificare;
• prove automatiche che verificano, a ogni modifica, che un utente di un cliente non possa accedere ai dati di un altro;
• file e documenti conservati in percorsi separati per cliente, con link temporanei.

Ogni cliente può personalizzare la piattaforma?

Sì, entro limiti decisi da chi la progetta. Le personalizzazioni tipiche sono:

• logo, colori e nome sul dominio del cliente;
• impostazioni, come valute, lingue, modelli di email;
• funzioni attivabili in base al piano sottoscritto;
• campi aggiuntivi nelle schede.

Quello che va evitato è il codice scritto apposta per un singolo cliente dentro la piattaforma comune. Ogni eccezione rende più difficili gli aggiornamenti per tutti. Se un cliente ha bisogno di qualcosa di molto particolare, meglio un'estensione separata o un'integrazione.

Come si aggiorna una piattaforma usata da tutti insieme?

Il vantaggio del multi-tenant, un aggiornamento per tutti, è anche la sua responsabilità: un errore in un aggiornamento colpisce tutti i clienti nello stesso momento. Per questo il processo di rilascio deve essere prudente:

1. ambiente di prova identico a quello reale, dove ogni modifica viene verificata prima;
2. prove automatiche che controllano le funzioni principali e la separazione dei dati;
3. modifiche al database compatibili con la versione precedente, così si può tornare indietro senza perdere dati;
4. rilasci in orari tranquilli e, quando possibile, senza interrompere il servizio;
5. funzioni nuove attivabili per pochi clienti prima di aprirle a tutti.

Un rilascio ben fatto è noioso: nessuno se ne accorge, se non per le novità.

Come si gestiscono backup e ripristino per un singolo cliente?

Con un database condiviso, il backup completo contiene i dati di tutti. Ma se un solo cliente cancella per errore una parte dei suoi dati e chiede di recuperarla, non si può ripristinare l'intero database: si cancellerebbero le modifiche fatte nel frattempo da tutti gli altri.

La soluzione è prevedere fin dall'inizio procedure di ripristino mirate, che estraggono da un backup solo i dati di quel cliente, o una funzione di cestino che conservi per un certo periodo i dati eliminati. Sono funzioni che non si vedono finché non servono, e quando servono fanno la differenza tra un problema risolto in un'ora e uno che dura giorni.

Cosa dice il GDPR su una piattaforma multi-cliente?

Quando un'azienda cliente inserisce nella tua piattaforma i dati dei suoi clienti, lei è titolare del trattamento e tu, che fornisci la piattaforma, ne sei di solito responsabile. L'articolo 28 del GDPR chiede che questo rapporto sia regolato da un accordo scritto, che stabilisce cosa puoi fare con quei dati, quali misure di sicurezza adotti, quali fornitori usi e cosa succede alla fine del contratto.

Dal lato tecnico, questo si traduce in alcune funzioni concrete:

• esportazione dei dati di un cliente, quando la chiede;
• cancellazione completa dei suoi dati alla chiusura del contratto;
• registrazione degli accessi alle informazioni più delicate;
• backup con tempi di conservazione definiti, e server preferibilmente nell'Unione europea.

Un cliente può avere più sedi o più aziende?

Spesso sì, ed è un caso da prevedere. Un cliente può gestire più sedi, più marchi o più società, e voler vedere tutto insieme pur tenendo separati dati e permessi. In ROOMIO, per esempio, più strutture si gestiscono da un solo account. Tecnicamente significa aggiungere un livello tra il cliente e i suoi dati, con utenti che vedono una sola sede e altri che le vedono tutte. Se non lo si prevede all'inizio, aggiungerlo dopo richiede di rivedere permessi e ricerche in tutta la piattaforma.

Le prestazioni di un cliente possono rallentare gli altri?

Può succedere, se un cliente molto grande o un'operazione pesante, come un'esportazione enorme, occupa le risorse comuni. Le contromisure sono limiti per cliente, operazioni pesanti eseguite in coda e non durante la navigazione, e un monitoraggio che segnali chi consuma di più.

Quando ha senso partire multi-tenant?

Quasi sempre, se il progetto è un software da vendere a più aziende. Trasformare dopo un software nato per un solo cliente in una piattaforma multi-cliente è uno dei lavori più costosi che conosca: bisogna rivedere quasi ogni parte del codice e del database.

Ha meno senso se il software è uno strumento interno per una sola azienda, o se i clienti saranno pochissimi e con esigenze completamente diverse. In quei casi una copia per cliente può essere la scelta più semplice. È una delle domande che affronto all'inizio di ogni progetto di piattaforma SaaS, e il motivo per cui anche in un MVP la separazione dei dati va impostata bene da subito.

Ne parliamo?

Se stai progettando un software da offrire a più aziende, o vuoi trasformare uno strumento nato per la tua attività in un prodotto per altri, scrivimi. Partiamo da chi saranno i clienti e da quanto devono essere separati, e scegliamo insieme l'architettura. Qui trovi come lavoro sulle piattaforme multi-cliente e sulle piattaforme SaaS, e un esempio concreto nel progetto ROOMIO.

Crediti delle immagini

• Copertina: foto di Giulia May su Unsplash