L'architettura multi-tenant spiegata senza tecnicismi: una guida per fondatori

A un certo punto, mentre si costruisce un prodotto software, uno sviluppatore Le dirà la parola "multi-tenant", osserverà la Sua espressione e darà per scontato che abbia capito. Probabilmente Lei ha annuito. La maggior parte dei fondatori lo fa. Ma questa è una di quelle decisioni iniziali che, in silenzio, fissa il tetto a quanto velocemente può crescere, a quanto economicamente può operare e a quanto male possono andare le cose se un cliente arriva a vedere dati che non sono i suoi. Merita dieci minuti della Sua attenzione adesso, perché tornarci sopra dopo è molto costoso.

Mi sono seduto di fronte a molti fondatori non tecnici — persone con un'idea brillante per un prodotto SaaS e senza particolare interesse per i database. La buona notizia è che non deve imparare a programmare per prendere bene questa decisione. Le serve un modello mentale chiaro e una breve lista di domande. È esattamente questo, questa guida. Niente parole di moda, niente diagrammi di architettura che non guarderà mai più, solo ciò che il Suo sviluppatore vorrebbe che Lei capisse prima della prima riga di codice.

Se porta via una sola idea, sia questa: il multi-tenancy non è una funzionalità che si aggiunge dopo. È una fondazione. Una casa la si può ridipingere, ma non è facile cambiare ciò su cui poggia una volta che i muri sono su.

Cosa significa davvero "multi-tenant"

Immagini un condominio. Ogni inquilino ha il proprio appartamento — la propria chiave, i propri mobili, la propria porta. Ma tutti condividono la stessa struttura: le fondamenta, gli impianti idraulici, il tetto, l'ascensore. Il proprietario gestisce un edificio, non cinquanta case separate, ed è questo che rende l'affitto sostenibile. Il software multi-tenant funziona esattamente così. Un'unica applicazione serve molti clienti — i "tenant" — e ciascuno la vive come il proprio spazio privato, anche se girano tutti sullo stesso sistema condiviso al di sotto.

L'approccio opposto è il single-tenant: ogni cliente riceve una propria copia separata del software, come costruire una casa indipendente nuova per ciascuno. Più privato, più personalizzabile — e drasticamente più costoso da costruire, far funzionare e aggiornare, perché ora gestisce cinquanta case invece di un edificio.

Quasi tutti i prodotti che usa ogni giorno sono multi-tenant. La Sua email, il Suo gestionale di contabilità, il Suo sistema di prenotazioni, il CRM in cui vive il Suo team commerciale. Lei e altre mille aziende condividete lo stesso software sottostante, e nessuno di voi vede mai gli altri. Quell'invisibilità — quella separazione pulita — è tutta l'arte del multi-tenancy.

Perché questa decisione tocca tutta la Sua attività

È tentante archiviare tutto questo sotto "dettaglio tecnico di cui si occupa il mio sviluppatore". Ma il modello che sceglie si ripercuote direttamente sulle parti dell'attività a cui tiene davvero: la Sua bolletta mensile di hosting, quanto in fretta può rilasciare una nuova funzionalità a tutti, cosa può promettere a un acquirente aziendale nervoso e quanto danno può fare un singolo bug.

Quando corregge un bug o pubblica una funzionalità in un prodotto multi-tenant ben costruito, tutti i clienti la ricevono in una volta, da un singolo aggiornamento. In un mondo single-tenant, dovrebbe distribuire quel cambiamento su cinquanta installazioni separate, ognuna magari un po' diversa ormai. Una cosa è un martedì pomeriggio. L'altra è un progetto. Moltiplichi tutto ciò su anni di aggiornamenti e capirà perché l'industria SaaS si regge sul multi-tenancy.

Il rovescio della medaglia è che condividere l'infrastruttura alza la posta sulla separazione. In un condominio, un guasto idraulico può colpire più di un appartamento. Nel software multi-tenant, un errore nel modo in cui tiene separati i tenant non disturba solo un cliente — può esporre i dati di tutti in una volta. Questo non è un motivo per evitare il multi-tenancy. È il motivo per costruirlo come si deve, con qualcuno che l'ha già fatto.

I tre modi di tenere separati i tenant

Quando gli sviluppatori discutono di multi-tenancy, di solito discutono di quanto separati debbano essere i dati di ciascun tenant. Ci sono tre approcci comuni, e si collocano su una scala scorrevole che va da "massima condivisione, costo minimo" a "massima separazione, costo massimo". Non deve sceglierne uno Lei stesso — ma dovrebbe capire il compromesso che il Suo sviluppatore sta facendo per Suo conto.

1. Database condiviso, tabelle condivise

I dati di tutti vivono nello stesso database, nelle stesse tabelle, con un'etichetta nascosta — un "ID tenant" — che segna quali righe appartengono a chi. Il software è responsabile di filtrare sempre in base a quell'etichetta, così che il cliente A veda sempre e solo le righe del cliente A. È il modello più economico e più scalabile, quello usato dalla maggior parte dei prodotti SaaS agli inizi. L'inghippo: la separazione vive nel codice, quindi un singolo filtro dimenticato è il modo in cui i dati trapelano. Richiede un'ingegneria attenta e disciplinata.

2. Database condiviso, scomparti separati

Un solo database, ma ogni tenant riceve al suo interno una propria sezione recintata (gli sviluppatori le chiamano "schemi"). Separazione più forte del primo modello, ancora ragionevolmente efficiente, e più facile, ad esempio, per esportare o cancellare in modo pulito i dati di un cliente. Il compromesso è più parti in movimento da gestire man mano che cresce verso centinaia e migliaia di tenant.

3. Un database separato per tenant

Ogni cliente riceve un proprio database dedicato — la cosa più vicina a dargli una casa privata pur continuando a condividere l'applicazione. È l'isolamento più forte e la storia più facile da raccontare a un acquirente aziendale attento alla sicurezza. È anche il più costoso da far funzionare e gestire, perciò tende a essere riservato a clienti di alto valore, settori regolamentati o prodotti in cui una confusione di dati sarebbe catastrofica.

La parte che non può sbagliare: l'isolamento

Se c'è un punto su cui spendere la Sua preoccupazione, è questo. L'isolamento dei tenant è la garanzia che il cliente A non possa mai, in nessuna circostanza, vedere, modificare o anche solo intuire l'esistenza dei dati del cliente B. Sembra ovvio. È anche la fonte singola più comune di bug gravi nei prodotti multi-tenant, perché il guasto è silenzioso — tutto sembra a posto fino al giorno in cui qualcuno apre un report e ci trova dentro i clienti di un estraneo.

Il motivo per cui accade è strutturale. Nel modello più economico, ogni singola richiesta al database deve ricordarsi di filtrare per tenant. La faccia bene diecimila volte e male una volta sola, e ha una fuga. È per questo che i team esperti non si affidano alla memoria degli sviluppatori — costruiscono l'isolamento nelle fondamenta, così che dimenticare diventi impossibile invece che semplicemente improbabile. Non deve capire come lo fanno. Deve chiedere se lo fanno.

C'è anche un cugino più sommesso di questo problema: il "vicino rumoroso". Poiché i tenant condividono l'infrastruttura, un cliente che fa qualcosa di pesante — un'importazione enorme, un report fuori controllo — può rallentare il sistema per tutti gli altri, allo stesso modo in cui un appartamento con tutti i rubinetti aperti può abbassare la pressione dell'acqua in tutto l'edificio. Una buona progettazione multi-tenant lo prevede con limiti e ripartizione equa. Vale la pena chiederlo, soprattutto se si aspetta qualche cliente molto grande.

Quando il single-tenant è davvero la scelta giusta

Il multi-tenancy è l'impostazione predefinita per il SaaS, ma non è una religione. Ci sono ragioni oneste per dare a un cliente una propria copia separata, e un buon consulente Le dirà quando ne ha incontrata una, invece di forzare tutto nel modello condiviso.

• Un cliente di un settore regolamentato — sanità, finanza, pubblica amministrazione — le cui regole di conformità di fatto impongono che i suoi dati risiedano in un luogo dimostrabilmente separato.
• Un singolo grande cliente che paga abbastanza da rendere conveniente una configurazione dedicata, e che desidera una personalizzazione profonda che non vuole far traboccare nell'esperienza di tutti gli altri.
• Dati così sensibili che il costo di una fuga fra tenant porrebbe fine all'attività, rendendo il massimo isolamento meritevole della spesa extra.
• Un requisito on-premise, in cui il software deve girare all'interno delle mura del cliente anziché nel Suo cloud.

Noti lo schema: il single-tenant è l'eccezione a cui ricorre deliberatamente, di solito per uno specifico cliente di alto valore, non l'impostazione predefinita su cui costruisce l'intera attività. Se uno sviluppatore propone il single-tenant per il Suo prodotto standard fin dal primo giorno, gli chieda di spiegarLe perché — di solito significa un costo operativo molto più alto e aggiornamenti più lenti, e Lei vuole che sia una scelta, non un incidente.

Le domande da porre prima che qualcuno scriva codice

Non deve progettare l'architettura. Deve assicurarsi che chi lo fa abbia pensato alle cose giuste. Ecco la breve lista che vorrei un fondatore non tecnico portasse a quella prima conversazione — la stampi, la ponga, osservi con quanta sicurezza Le viene risposto.

1. 1
   Come terrete separati i dati dei tenant?

   Aspetta una risposta strutturale — è il sistema a imporlo — non un "staremo attenti". Questa è la domanda non negoziabile.
2. 2
   Quale modello stiamo usando, e perché?

   Tabelle condivise, scomparti separati o database per tenant. Non c'è una risposta sbagliata, ma dovrebbe esserci una ragione adatta ai Suoi clienti e al Suo budget.
3. 3
   Potremo offrire un isolamento dedicato a un grande cliente in seguito?

   Anche se parte completamente condiviso, il progetto dovrebbe lasciare spazio per dare a un cliente grande o regolamentato una separazione più forte senza una ricostruzione.
4. 4
   Cosa succede quando un cliente diventa enorme?

   Come fa il sistema a impedire che un tenant pesante rallenti tutti gli altri? Vuole sentire che gli scenari di vicino rumoroso sono stati considerati.
5. 5
   Come esportiamo o cancelliamo in modo pulito i dati di un cliente?

   I clienti se ne vanno, e la legge sulla privacy impone di rimuovere i loro dati su richiesta. Dovrebbe essere un'operazione semplice e ben compresa, non un'emergenza.

Non sta valutando il dettaglio tecnico delle risposte. Sta verificando che nessuna di queste domande arrivi come una sorpresa. Un team che ha già costruito software multi-tenant avrà risposte nitide, quasi annoiate, a tutte e cinque. Un'esitazione sulla prima o sulla terza è il segnale per rallentare e approfondire.

Un breve esempio, ispirato alla realtà

Un fondatore è venuto da noi con un prototipo funzionante di uno strumento di prenotazione appuntamenti pensato per piccole cliniche. Aveva già tre clienti paganti — e un problema silenzioso. Per arrivare in fretta sul mercato, il primo sviluppatore aveva dato a ogni clinica una propria copia separata dell'app. Tre clienti, tre installazioni, tre versioni leggermente diverse, perché ognuna lungo il percorso aveva chiesto una piccola modifica.

A tre funzionava a meraviglia. L'incubo del fondatore era il pensiero di trenta. Ogni correzione di bug significava accedere in tre posti. Ogni nuova funzionalità significava tre distribuzioni e tre cose da testare. Avviare una nuova clinica richiedeva quasi una settimana a mano. Il modello che li aveva portati al lancio era ora ciò che frenava la loro crescita — esattamente il problema di fondamenta di cui tratta tutto questo articolo.

Non abbiamo strappato via tutto in una riscrittura drammatica. Abbiamo ricostruito il nucleo su una fondazione multi-tenant condivisa, con l'isolamento imposto a livello di sistema, abbiamo mantenuto le personalizzazioni per clinica come impostazioni configurabili anziché basi di codice separate e abbiamo migrato le tre cliniche esistenti una alla volta, in parallelo, così che nessuno avesse un giorno di passaggio spaventoso. Avviare una nuova clinica è passato da una settimana di lavoro manuale a una registrazione self-service. Le nuove funzionalità ora raggiungono ogni cliente da un singolo rilascio.

I numeri qui sono indicativi, non una promessa — ogni prodotto è diverso —, ma la forma è tipica: la ricostruzione è costata denaro vero e un paio di mesi, e si è ripagata già con la prima manciata di nuovi clienti che hanno potuto improvvisamente integrare senza muovere un dito. La lezione che il fondatore ha portato via è stata quella più economica: se avessero posto le cinque domande all'inizio, non ci sarebbe stato nulla da ricostruire.

Domande frequenti