Ogni piattaforma SaaS multi-tenant risponde alla stessa domanda — come vengono tenuti separati i dati di un tenant da quelli di un altro, su un'unica codebase condivisa? — ma la risposta corretta dipende dal profilo di rischio della piattaforma. Due piattaforme, Omnitech CRM e IMFlow360, rispondono in modo diverso, ed entrambe le risposte sono corrette per ciò di cui ciascuna piattaforma necessita.
01Come leggere il lavoro
Due strategie di isolamento, in linea generale
Le piattaforme multi-tenant isolano generalmente i tenant a uno di alcuni livelli possibili: un database separato per tenant, uno schema separato per tenant, oppure tabelle condivise delimitate da un identificatore di tenant a livello applicativo. Ciascuna soluzione ha un costo e una modalità di fallimento diversi; la guida AWS sull'isolamento dei tenant nel SaaS è un utile riferimento pubblico sui compromessi tra queste strategie (citata di seguito). Omnitech CRM e IMFlow360 utilizzano entrambe un isolamento applicato a livello applicativo su tabelle condivise — ma lo applicano in modo diverso.
02Come leggere il lavoro
Omnitech CRM: fail-closed ai livelli del modello e della query
Omnitech CRM applica l'isolamento dei tenant ai livelli del modello e della query, incluso il lavoro in background accodato, secondo un principio fail-closed: se a una query manca lo scope tenant, la richiesta fallisce anziché rischiare una dispersione di dati tra tenant. Un registro dei permessi centralizzato — 126 permessi distribuiti su 22 moduli aziendali — viene mantenuto deliberatamente separato da questo livello di isolamento, così i permessi possono essere ampliati o ristretti per un ruolo senza mai intervenire sul percorso di codice responsabile di mantenere separati i tenant.
03Come leggere il lavoro
IMFlow360: tenancy basata su righe, differenziata per tipo di business
IMFlow360 adotta un approccio correlato ma distinto: la multi-tenancy basata su righe delimita ogni record per business e filiale, mentre un campo business_type — non una codebase duplicata — differenzia il comportamento di catalogo, ordini e workflow per attività di retail, ristorazione, bellezza/saloni/spa e attività basate su appuntamenti. Tutti e quattro i settori operano su un unico schema condiviso di circa 146 tabelle. Il confine di isolamento è lo stesso pattern a tabelle condivise di Omnitech CRM; la differenza è che IMFlow360 utilizza lo stesso meccanismo di delimitazione anche per differenziare il comportamento del business, non solo per separare i dati dei tenant.
04Come leggere il lavoro
La lezione effettiva
La strategia di isolamento è una decisione fondamentale presa una sola volta, in una fase iniziale, in base al profilo di rischio della piattaforma — ed è una decisione separata dal sistema di permessi costruito sopra di essa. Entrambe le piattaforme applicano l'isolamento a livello applicativo su tabelle condivise; la differenza tra un'applicazione fail-closed delimitata rigorosamente ai confini del tenant, e una delimitazione per riga che porta con sé anche la differenziazione del comportamento per tenant, dipende da cosa ciascuna piattaforma necessitava che il meccanismo di delimitazione facesse oltre al semplice isolamento.
