Architettura multi-tenant: una guida pratica per gli architetti
Architettura multi-tenant: una guida pratica per gli architetti L'architettura multi-tenant è un approccio alla progettazione software in cui una singola istanza applicativa serve più clienti — chiamati tenant — mantenendo al contempo i dati e il comportamento di ciascun tenant isolati da quelli degli altri.
Architettura multi-tenant: una guida pratica per gli architetti
L'architettura multi-tenant è un approccio alla progettazione software in cui una singola istanza applicativa serve più clienti — chiamati tenant — mantenendo al contempo i dati e il comportamento di ciascun tenant isolati da quelli degli altri. La conclusione pratica sulla scelta del modello: considerate la tenancy come una decisione di prodotto articolata per livelli. Iniziate con un modello pooled per i clienti sensibili ai costi e a rischio più basso; usate un modello ibrido o bridge quando il mix di clienti è eterogeneo; e predisponete un'infrastruttura silo dedicata per i tenant aziendali o soggetti a normative che richiedono un isolamento contrattuale.
I tre principali compromessi che ogni team deve gestire:
-
Isolamento rispetto ai costi: Un isolamento più forte richiede risorse dedicate, con una spesa maggiore per tenant.
-
Complessità rispetto alla flessibilità: I modelli condivisi sono più economici da gestire, ma richiedono un'applicazione rigorosa a livello applicativo per prevenire fughe di dati.
-
Velocità rispetto alla conformità: Le architetture pooled attivano i tenant in pochi secondi; i modelli silo possono richiedere da alcuni minuti a diverse ore, ma soddisfano i revisori e i team di approvvigionamento aziendale.
Indice
-
Come si scala una piattaforma multi-tenant senza compromettere le prestazioni?
-
Come si presentano in pratica le architetture di riferimento?
-
Come Ridiculous Engineering affronta l'architettura multi-tenant
-
Lavorare con Ridiculous Engineering sulla vostra piattaforma multi-tenant
Che cosa significa davvero «multi-tenant»?
Un tenant è un'organizzazione, un account o un'unità cliente logica distinta che condivide la piattaforma. Una singola azienda può avere migliaia di utenti, ma tutti appartengono a un unico tenant. Il confine del tenant è la linea logica o fisica che separa i dati, la configurazione e il comportamento di un tenant da quelli di un altro.
A differenza dell'architettura single-tenant, in cui ogni cliente riceve un'istanza applicativa e un database dedicati. Le implementazioni single-tenant sono più semplici da comprendere, ma costose da gestire su larga scala. Il multi-tenancy consente a una singola istanza applicativa di servire molti clienti; per questo la maggior parte delle piattaforme SaaS lo adotta per scalare da decine a migliaia di clienti senza riprogettare il sistema di base.
Gli obiettivi aziendali che spingono i team verso il multi-tenancy sono costanti: ridurre il costo dell'infrastruttura per cliente, disporre di un'unica superficie di distribuzione per aggiornamenti e patch e diminuire il carico operativo. Anche gli obiettivi tecnici sono altrettanto costanti: isolamento dei dati tra tenant, instradamento delle richieste consapevole del tenant, monitoraggio per tenant e possibilità di applicare configurazioni o set di funzionalità diversi per account.
Quali sono i principali modelli di tenancy?
Indicazioni di AWS presenta l'isolamento come un continuum dal modello Silo al modello Pool, con modelli Bridge intermedi. Questa impostazione è il modello mentale più utile per prendere decisioni architetturali.
Silo (stack dedicato per tenant)
Ogni tenant dispone del proprio stack applicativo e database. L’isolamento è massimo: un bug, una violazione o un carico di lavoro rumoroso in un tenant non può influire sugli altri. Gli auditor della conformità lo apprezzano perché è semplice dimostrare la localizzazione dei dati e i controlli di accesso. Il costo, però, è reale. Il sovraccarico dell’infrastruttura cresce linearmente con il numero di tenant e la complessità operativa aumenta a ogni nuova distribuzione. Il ripristino per tenant è semplice perché ogni database è già circoscritto a un singolo cliente.
Schema per tenant (database condiviso, schemi separati)
Tutti i tenant condividono un motore di database, ma ciascuno dispone del proprio schema. Questo modello si colloca tra il silo e il pooling completo: offre una separazione logica significativa senza il costo di istanze di database separate. Lo schema per tenant funziona bene quando il numero di tenant è nell’ordine delle centinaia anziché delle migliaia, perché la proliferazione degli schemi crea alla fine problemi di migrazione e di gestione del pool di connessioni. Le migrazioni online degli schemi richiedono un’attenta gestione delle versioni per evitare di bloccare più tenant contemporaneamente.
Schema condiviso (isolamento a livello di riga)
Un database, uno schema, con le righe di ogni tenant che coesistono nelle stesse tabelle. Questo è il modello meno costoso e quello che richiede maggiore disciplina. La sicurezza a livello di riga richiede un filtro tenant_id in ogni lettura e scrittura. Basta dimenticare una query e si verifica una fuga di dati. Le policy di Row Level Security (RLS) di PostgreSQL o il middleware a livello applicativo possono applicarlo automaticamente, ma il rischio di omettere un filtro è reale e le conseguenze sono gravi.
Modelli bridge e ibridi
Un modello bridge combina il calcolo condiviso con diversi gradi di isolamento dello storage. Un pattern comune prevede un livello applicativo condiviso, ma database separati per tenant per l’archiviazione. Il pattern Deployment Stamps di Azure porta questo concetto oltre, distribuendo un’infrastruttura dedicata per un tenant o un gruppo di tenant e aumentando poi la capacità aggiungendo stamp. Gli stamp possono essere a tenant singolo o multi-tenant, offrendo ai team un percorso di aggiornamento chiaro quando un tenant con risorse condivise supera i limiti dell’ambiente condiviso.
Confronto dei modelli di tenancy
| Dimensione | Silo | Schema per tenant | Schema condiviso | Bridge/Ibrido |
|---|---|---|---|---|
| Livello di isolamento | Forte (fisico) | Moderato (logico) | Debole (applicato dall’applicazione) | Configurabile |
| Costo per tenant | Alto | Medio | Basso | Medio-alto |
| Complessità di implementazione | Alta (sovraccarico operativo) | Media | Bassa-media | Alta |
| Scalabilità | Crescita lineare dei costi | Centinaia di tenant | Migliaia di tenant | Flessibile |
| Idoneità alla conformità | Eccellente | Buona | Richiede prove | Buono-Eccellente |
| Capacità di personalizzazione | Completa | Elevata | Limitata | Elevata |
Consiglio professionale: Non considerare questa tabella una risposta definitiva. La maggior parte delle piattaforme in produzione finisce per utilizzare contemporaneamente almeno due modelli: pool per i livelli standard, silo o stamp per i contratti enterprise. Progetta le tue astrazioni in modo da supportarli entrambi fin dal primo giorno.
Come si sceglie il modello di multi-tenancy più adatto?
La decisione non è puramente tecnica. Trattare la multi-tenancy come una funzionalità del prodotto — qualcosa a cui attribuire un prezzo e da includere nei pacchetti — è ciò che distingue le piattaforme che acquisiscono ricavi enterprise da quelle che li lasciano sul tavolo.
Valuta questi criteri nell’ordine seguente:
-
Requisiti normativi e di conformità. Se un tenant sarà soggetto a HIPAA, PCI DSS o agli audit SOC 2 Type II, inizia con il modello silo o con uno schema per tenant per quegli account. L’isolamento tramite schema condiviso è difficile da sottoporre a un audit convincente.
-
Residenza contrattuale dei dati. I clienti enterprise richiedono sempre più spesso che i dati rimangano entro specifici confini geografici. I modelli silo o stamp rendono tutto questo semplice; i modelli con schema condiviso richiedono controlli accurati a livello di database.
-
Impegni SLA enterprise. Se prometti un’operatività del 99,9% o superiore con finestre di supporto dedicate, un vicino rumoroso in un modello pool rappresenta un rischio per lo SLA.
-
Sensibilità al prezzo della tua clientela. I clienti SMB e self-service raramente pagano abbastanza da giustificare un’infrastruttura dedicata. Inizia con il modello pool per questi segmenti.
-
Maturità del team e livello di automazione. I modelli silo richiedono un’automazione matura dell’infrastruttura. Se il tuo team non riesce a eseguire il provisioning dello stack di un nuovo tenant in meno di cinque minuti senza alcun passaggio manuale, il sovraccarico operativo ti danneggerà.
-
Variabilità del carico di lavoro. I carichi di lavoro altamente variabili o intermittenti traggono vantaggio dalle risorse in pool, perché i carichi non correlati appiattiscono i rapporti tra picco e media. I tenant prevedibili e ad alto volume sono candidati migliori per risorse dedicate.
Il flusso decisionale pratico: inizia con il modello pool se il profilo dei clienti è sconosciuto o dominato dalle SMB. Passa a un modello ibrido non appena acquisisci il primo cliente enterprise con requisiti di isolamento. Riserva il modello silo completo ai settori regolamentati o ai clienti con obblighi contrattuali di residenza dei dati.
Consiglio professionale: Evita la trappola del tutto o niente. Le piattaforme che adottano un unico modello di multi-tenancy per tutti i clienti finiscono per spendere troppo per l’isolamento degli account a basso valore oppure perdono contratti enterprise perché non possono offrire un’infrastruttura dedicata. Integra il livello di multi-tenancy nel tuo modello di pricing fin dall’inizio, anche se oggi disponi di un solo livello.
I team che iniziano con un modello completamente pool per risparmiare sui costi spesso si trovano ad affrontare problemi di vicini rumorosi, costosi da risolvere in seguito. Iniziare con un modello ibrido — pool per i livelli inferiori, isolamento per l’enterprise — evita il costo di questa ristrutturazione architetturale. Allineare le decisioni sulla multi-tenancy agli obiettivi aziendali fin dalle prime fasi è una delle decisioni a più alto impatto che un team di architettura possa prendere.
Checklist di implementazione per sistemi multi-tenant
Definire correttamente il modello architetturale è metà del lavoro. L’altra metà consiste nella disciplina ingegneristica necessaria per implementarlo correttamente. Questi sono gli elementi costitutivi più importanti.
Identità e instradamento dei tenant
-
Assegna a ogni tenant un
tenant_idstabile e immutabile al momento della creazione e trattalo come un elemento di primo livello in ogni strato dello stack. -
Propaga il contesto del tenant durante tutto il ciclo di vita della richiesta: intestazioni HTTP, middleware, connessioni al database e code di job asincroni devono trasportarlo tutti.
-
Utilizza l’instradamento tramite sottodominio (
tenant.app.com), l’instradamento basato sul percorso (/api/tenant/{id}/) o le attestazioni JWT per risolvere l’identità del tenant al perimetro, prima che la richiesta raggiunga la logica applicativa.
Partizionamento dei dati e pooling delle connessioni
-
Per i modelli con schema condiviso, applica automaticamente i filtri
tenant_idnel livello di accesso ai dati, non nel punto di chiamata. Codificare la logica del tenant nel punto di chiamata crea sottili falle di sicurezza e debito di manutenzione. -
Usa PgBouncer o un connection pooler simile per gestire in modo efficiente le connessioni al database tra grandi pool di tenant; i limiti di connessione per tenant impediscono a un singolo tenant di esaurire il pool.
-
Per i modelli con uno schema per tenant, automatizza la creazione e la distruzione degli schemi come parte del ciclo di provisioning e dismissione.
Autenticazione e autorizzazione
-
Supporta provider di identità specifici per tenant: i clienti aziendali vorranno utilizzare il proprio provider SAML o OIDC.
-
Applica ruoli e autorizzazioni con ambito limitato al tenant, in modo che un utente autenticato nel Tenant A non possa accedere alle risorse del Tenant B, anche con un token valido.
-
Usa strumenti come Auth0, Okta o AWS Cognito con attestazioni consapevoli del tenant per evitare di costruire da zero l’infrastruttura delle identità.
Provisioning e migrazioni
-
Automatizza completamente il provisioning dei tenant. Se il provisioning richiede scritture manuali nello schema o interventi umani, il sistema è di fatto multiistanza, non multi-tenant.
-
Versiona tutte le migrazioni dello schema e applicale in modo compatibile con le versioni precedenti, così da poter distribuire modifiche a migliaia di tenant senza tempi di inattività.
-
Mantieni un registro dei tenant (un archivio di metadati) che tenga traccia del livello, della configurazione, dello stato di provisioning e delle risorse assegnate a ciascun tenant.
Backup, DR e misurazione dei consumi
-
Definisci SLA di ripristino per tenant e testa le procedure di ripristino per singoli tenant, non solo i ripristini dell’intero database.
-
Raccogli fin dal primo giorno le metriche di utilizzo per tenant (chiamate API, spazio di archiviazione, calcolo) e integrale con il sistema di fatturazione. Piattaforme come Manaxo illustrano concretamente come i prodotti SaaS associano i dati di utilizzo ai livelli di fatturazione.
-
Applica quote e limiti di frequenza per tenant per proteggere le risorse condivise.
CI/CD e strategia di rilascio
-
Usa i feature flag per distribuire le modifiche a un sottoinsieme di tenant prima del deployment completo. È il modo più sicuro per testare personalizzazioni specifiche per tenant senza mettere a rischio l’intero parco.
-
Automatizza le pipeline CI/CD per distribuire la configurazione specifica del tenant insieme al codice applicativo.
-
Antipattern da evitare: logica del tenant codificata nel codice applicativo, passaggi manuali di provisioning e osservabilità insufficiente per tenant.
Consiglio dell’esperto: Configura il sistema affinché emetta metriche e log contrassegnati con il tenant fin dal primo giorno di sviluppo. Aggiungere l’osservabilità a posteriori in una piattaforma multi-tenant già operativa è complesso e costoso. Il logging consapevole del tenant non è facoltativo — è l’unico modo per eseguire il debug dei problemi in produzione senza esporre i dati di un tenant mentre si indagano quelli di un altro.
Sicurezza e conformità negli ambienti multi-tenant
La sicurezza multi-tenant non consiste in un singolo controllo. È un insieme stratificato di decisioni che si amplificano in tutta l’architettura.
-
Crittografia dei dati a riposo e in transito: Crittografa tutti i dati dei tenant a riposo usando AES-256 o un equivalente e applica TLS 1.2+ per tutti i dati in transito. Per i tenant altamente regolamentati, valuta la crittografia a livello di campo per le colonne sensibili, in modo che nemmeno gli amministratori del database possano leggere i valori grezzi.
-
IAM con ambito limitato al tenant: Applica controlli di accesso con il minimo privilegio a ogni livello. Le policy Cloud IAM, i ruoli del database e le autorizzazioni dell’applicazione dovrebbero essere tutti limitati al tenant. Nessun accesso tra tenant dovrebbe essere possibile attraverso i normali percorsi applicativi.
-
Logging di audit: Contrassegna ogni voce di log con
tenant_id, archivia i log in un sistema a prova di manomissione (AWS CloudTrail, Azure Monitor Logs) e conservali per il periodo richiesto dalle normative applicabili. Gli auditor SOC 2 lo richiederanno. -
Residenza dei dati: Per i requisiti statunitensi di residenza dei dati, utilizza il blocco della regione cloud e conferma che anche i servizi gestiti (backup, repliche, esportazioni di analisi) rimangano nella regione richiesta. I modelli a silo e a stampo rendono più semplice dimostrarlo.
-
PCI DSS: I dati dei titolari di carta devono essere isolati. Un modello con schema condiviso non è una soluzione praticabile per rientrare nell'ambito PCI senza significativi controlli compensativi. La scelta pratica è il modello a silo o con uno schema per tenant.
-
HIPAA: Le informazioni sanitarie protette richiedono un Business Associate Agreement con il provider cloud e controlli degli accessi dimostrabili. Le chiavi di crittografia per tenant e i log di audit sono requisiti di base.
-
Contenimento delle violazioni: Progetta i confini tra tenant in modo che una credenziale dell'applicazione compromessa non possa attraversare i confini dei tenant. Le chiavi di crittografia per tenant fanno sì che la compromissione di una chiave riguardi un solo tenant, non tutti.
-
Risposta agli incidenti: Mantieni runbook per tenant, così il team reperibile può isolare, analizzare e ripristinare un singolo tenant senza influire sugli altri. Resilienza operativa la pianificazione dovrebbe includere scenari di incidente specifici per tenant.
Questo articolo contiene indicazioni tecniche generali, non consulenza legale o in materia di conformità. Verifica i tuoi specifici obblighi normativi con un legale qualificato e con il tuo team di compliance.
Come si scala una piattaforma multi-tenant senza compromettere le prestazioni?
La scalabilità di una piattaforma multi-tenant riguarda meno la capacità grezza e più la protezione dei tenant reciproci, mantenendo al contempo prevedibili i costi.
-
Raggruppa i carichi di lavoro non correlati. Raggruppare tenant con modelli di utilizzo non correlati appiattisce i rapporti tra carico di picco e carico medio sulle risorse condivise. Un tenant il cui picco si verifica il lunedì mattina abbinato a uno il cui picco si verifica il venerdì pomeriggio costituisce un pool migliore di due tenant con picchi identici il lunedì mattina. Questa è una delle decisioni di pianificazione della capacità con il maggiore impatto a disposizione dei team di piattaforma.
-
Quote e limitazione della velocità per tenant. Applica limiti di velocità alle API, limiti di tempo per le query e quote di archiviazione per tenant. Quando un tenant raggiunge un limite, limita la velocità o accoda le sue richieste invece di permettere che degradi il pool. Questa è la principale misura di mitigazione del problema del vicino rumoroso.
-
Escalation della topologia. Quando il carico di lavoro di un tenant supera costantemente ciò che il throttling può contenere, spostalo a un livello di risorse dedicato. Questo non è un fallimento dell'architettura; è il percorso di aggiornamento che funziona come previsto.
-
Autoscaling e serverless. Il calcolo serverless (AWS Lambda, Azure Functions) gestisce bene i carichi di lavoro variabili nei livelli condivisi, perché si paga per invocazione anziché per istanza predisposta. Per le distribuzioni a stampo, i gruppi di autoscaling con capacità preriscaldata gestiscono la crescita prevedibile. Consulta per i modelli di scalabilità dell'infrastrutturaper i modelli di scalabilità dell'infrastruttura
-
Scalabilità del database. Il connection pooling è fondamentale su larga scala. Per i modelli con schema condiviso, una singola istanza PgBouncer può gestire migliaia di connessioni dei tenant verso un numero ridotto di connessioni effettive al database. Per lo schema per tenant, Aurora Serverless o database gestiti simili riducono il costo degli schemi inattivi.
-
Metriche e attribuzione dei costi per tenant. Strumenta la piattaforma per attribuire i costi di calcolo, archiviazione e rete ai singoli tenant. Questi dati guidano le decisioni sui prezzi e identificano i tenant il cui utilizzo non copre i costi dell'infrastruttura.
Come si gestisce l'intero ciclo di vita di un tenant?
La multi-tenancy è una funzionalità del prodotto, non solo una questione tecnica. Il ciclo di vita, dall'onboarding all'offboarding, deve essere pianificato con la stessa attenzione di qualsiasi altra funzionalità del prodotto.
-
Provisioning senza intervento umano: I tenant nei pool devono essere configurati completamente in pochi secondi tramite una pipeline automatizzata: creare il record del tenant, assegnare
tenant_id, applicare la configurazione predefinita e inviare le credenziali di benvenuto. Nessun passaggio umano. Automatizzare l'onboarding è ciò che distingue una piattaforma da una raccolta di istanze gestite manualmente. -
Artefatti del provisioning: Ogni evento di provisioning di un tenant dovrebbe produrre un insieme completo di artefatti: creazione dello schema o del database, blocchi di configurazione, segreti archiviati in un secrets manager (AWS Secrets Manager, HashiCorp Vault), chiavi API e una voce nel registro dei metadati dei tenant.
-
Aggiornamenti di livello e migrazioni:Definisci un percorso di upgrade chiaro per spostare un tenant dal modello condiviso al modello con uno schema per tenant, quindi a un database dedicato e infine a un silo completo. Ogni passaggio deve essere automatizzato e testato. Le linee guida di Azure sui modelli di tenancy descrivono come le piattaforme di successo utilizzino livelli condivisi per gli utenti standard e stamp isolati per i clienti enterprise; questo schema richiede un percorso di migrazione testato tra i diversi livelli.
-
Gestione delle personalizzazioni:Usa i feature flag (LaunchDarkly, Unleash o un archivio di flag sviluppato internamente) per gestire la disponibilità delle funzionalità specifiche per tenant. Archivia la configurazione dei tenant in un archivio di configurazione dedicato, non nel codice dell'applicazione. I punti di estensione devono essere ben definiti e isolati in sandbox.
-
Fatturazione e misurazione dei consumi:Raccogli continuamente le metriche di utilizzo e associarle ai livelli di fatturazione. Per i prodotti SaaS regolamentati, piattaforme come Intelligent Assessmentsdimostrano come i prezzi a livelli siano associati a segmenti di clientela sensibili alla conformità. Applica quote rigide prima della chiusura dei cicli di fatturazione per evitare costi aggiuntivi imprevisti.
-
Disattivazione:Definisci un processo di eliminazione dei tenant che rimuova o archivi tutti i dati del tenant, revochi le credenziali, rilasci le risorse e produca un record di audit dell'eliminazione. Sia il GDPR sia il CCPA richiedono una cancellazione dei dati dimostrabile su richiesta.
Come si presentano in pratica le architetture di riferimento?
Linee guida AWS per il multi-tenancy
Le linee guida AWS per le architetture multi-tenant organizzano lo spazio delle soluzioni lungo il continuum Silo/Bridge/Pool. In un'architettura AWS condivisa, i tenant condividono le risorse di calcolo ECS o Lambda, un singolo cluster RDS o Aurora e un API Gateway condiviso con autorizzatori consapevoli del tenant. In un'architettura a silo, ogni tenant dispone di una propria VPC, di un'istanza RDS e di un confine basato sui ruoli IAM. Il modello bridge condivide in genere il calcolo (task ECS o Lambda), isolando al contempo lo storage (istanze RDS per tenant oppure prefissi S3 con policy dei bucket).
AWS consiglia di utilizzare Amazon Cognito con attributi personalizzati per un'identità consapevole del tenant, AWS IAM per l'isolamento a livello di risorsa nei modelli a silo e Amazon CloudWatch con metriche associate ai tenant per l'osservabilità in tutti i modelli.
Stamp di distribuzione Azure
L'Azure Architecture Center di Microsoft descrive il pattern Deployment Stamps come un modo per scalare le piattaforme multi-tenant distribuendo unità di infrastruttura autonome. Uno stamp può servire un tenant enterprise (stamp single-tenant) oppure un gruppo di tenant condivisi (stamp multi-tenant). Aggiungere capacità significa aggiungere stamp, non scalare un cluster monolitico condiviso. Questo approccio offre ai team solide garanzie di isolamento, mantenendo al contempo la possibilità di raggruppare tenant più piccoli all'interno di uno stamp.
Salesforce come esempio canonico
Salesforce è l'esempio più citato di multi-tenancy su larga scala nel SaaS enterprise. La piattaforma serve centinaia di migliaia di organizzazioni su un'infrastruttura condivisa, utilizzando una combinazione di isolamento a livello applicativo, metadati per tenant e un motore di query proprietario che applica i confini tra tenant a livello di accesso ai dati. La lezione fondamentale dell'architettura Salesforce non riguarda la tecnologia specifica, ma il principio: l'isolamento dei tenant deve essere applicato a livello di dati, non lasciato alla memoria dei singoli sviluppatori nel punto di chiamata.
SAP BTP e piattaforme enterprise
Architettura di riferimento di SAP per il SaaS multi-tenant su BTPsegue principi simili: isolamento dei tenant, onboarding e disattivazione automatizzati, condivisione delle risorse con controlli di governance e configurazione a livello di tenant per le estensioni enterprise. Le piattaforme enterprise convergono costantemente sugli stessi pattern, indipendentemente dallo stack tecnologico sottostante.
Come Ridiculous Engineering affronta l'architettura multi-tenant
Ridiculous Engineering è una società di consulenza di ingegneria del software con sede in Colorado, che ha progettato e realizzato piattaforme multi-tenant in produzione per clienti di settori regolamentati, startup SaaS e team di software enterprise. Il nostro processo è metodico e inizia dalla fase di analisi prima di scegliere qualsiasi modello.
Un incarico tipico segue questa sequenza:
-
Analisi e mappatura dei vincoli:Documentiamo gli obiettivi SLA, i requisiti di conformità (HIPAA, PCI, SOC 2), la scala prevista dei tenant a 12 e 36 mesi, i requisiti di personalizzazione e il livello di maturità dell'automazione del team. Questi input determinano il modello di tenancy iniziale.
-
Scelta del modello di tenancy e progettazione dell'architettura:Raccomandiamo un modello iniziale e definiamo il percorso di upgrade. Per la maggior parte dei clienti, questo significa iniziare con un modello condiviso e un percorso di migrazione definito verso il modello con uno schema per tenant o verso un silo per gli account enterprise.
-
Automazione e provisioning:Realizziamo pipeline di provisioning dei tenant senza interventi manuali prima di scrivere le funzionalità dell'applicazione. Il provisioning è un deliverable ingegneristico di primo livello, non un'attività secondaria.
-
Implementazione graduale:Implementiamo i controlli di tenancy a livello di accesso ai dati, non nel punto di chiamata, e li validiamo con test automatizzati che simulano tentativi di accesso tra tenant.
-
Runbook e passaggio al team operativo:Forniamo runbook documentati per l'onboarding dei tenant, gli upgrade di livello, la risposta agli incidenti e la disattivazione, affinché il vostro team possa gestire la piattaforma in autonomia.
Il nostro lavoro sulla piattaforma CMS di Consusillustra come una visione a livello di piattaforma dell'isolamento dei tenant e dell'architettura cloudsi traduca in sistemi di produzione scalabili senza dover riprogettare l'architettura. Valutiamo gli stessi vincoli in ogni incarico: controlli di conformità, scala prevista dei tenant, profondità della personalizzazione e capacità del team di gestire ciò che realizziamo.
Punti chiave
Considera la tenancy come una decisione di prodotto a livelli: inizia con un modello condiviso per l'efficienza dei costi, aggiungi livelli di isolamento quando lo richiedono i requisiti di conformità e enterprise e automatizza ogni fase del ciclo di vita del tenant fin dal primo giorno.
| Punto | Dettagli |
|---|---|
| Inizia con un modello condiviso o pooled, pianificando l'isolamento | Inizia con un modello a schema condiviso o pooled per i clienti SMB e definisci il percorso di aggiornamento al modello silo prima di averne bisogno. |
| Imponi tenant_id a livello di dati | Applica automaticamente i filtri del tenant a livello di accesso ai dati, non nei singoli punti di chiamata, per prevenire fughe di dati. |
| Automatizza completamente il provisioning | I passaggi manuali di provisioning indicano che hai un'architettura multi-istanza, non multi-tenant; l'onboarding con un clic è una base imprescindibile. |
| Implementa presto metriche per tenant | Contrassegna log e metriche con tenant_id fin dal primo giorno; aggiungere l'osservabilità a una piattaforma già operativa è costoso e soggetto a errori. |
| Ridiculous Engineering progetta questo | Ridiculous Engineering realizza piattaforme multi-tenant pronte per la produzione, con provisioning automatizzato, isolamento a livelli e un'architettura pronta per la conformità. |
Fonti utili e ulteriori letture
Gli architetti che desiderano approfondire i dettagli di implementazione hanno a disposizione diversi riferimenti autorevoli da aggiungere ai segnalibri:
-
Linee guida AWS per le architetture multi-tenant: Il riferimento principale di AWS per il continuum Silo/Bridge/Pool, con architetture di esempio, costrutti CDK e indicazioni sull'identità consapevole del tenant tramite Amazon Cognito.
-
Azure Architecture Center: soluzioni multi-tenant: La serie completa di Microsoft che tratta considerazioni architetturali, deployment stamp, indicazioni specifiche per i servizi e una checklist pratica di implementazione per piattaforme multi-tenant ospitate su Azure.
-
Modelli di tenancy Azure: Indicazioni mirate sulla scelta tra i modelli di tenancy, con analisi dei compromessi e raccomandazioni sul percorso di aggiornamento.
-
Shopify: best practice per le architetture multi-tenant: Una panoramica orientata ai professionisti su come gli sviluppatori di app passano da decine a migliaia di merchant, con modelli di implementazione concreti.
-
SAP Architecture Center: SaaS multi-tenant su BTP: Architettura di riferimento incentrata sulle aziende, che tratta isolamento dei tenant, onboarding, governance delle risorse e gestione della configurazione per le estensioni SAP BTP.
-
Risorse di Ridiculous Engineering: Per assistenza sull'implementazione, casi di studio e consulenze architetturali, visita ridiculousengineering.com.
Collaborare con Ridiculous Engineering sulla tua piattaforma multi-tenant
Costruire correttamente una piattaforma multi-tenant fin dall'inizio costa meno che correggerne una costruita male. La decisione architetturale più costosa che la maggior parte dei team prende è impegnarsi in un singolo modello di tenancy senza un percorso di migrazione, per poi scoprire due anni dopo che la pipeline aziendale richiede un isolamento dedicato che non sono in grado di fornire.
Ridiculous Engineering custom software developmentLa pratica è incentrata esattamente su questo tipo di lavoro architetturale: innanzitutto la fase di scoperta, guidata dai vincoli e fornita con l’automazione e la documentazione di cui il vostro team ha bisogno per gestirla a lungo termine. Collaboriamo con startup SaaS, piattaforme in crescita e aziende consolidate in Colorado e oltre. Se state progettando un nuovo sistema multi-tenant o modernizzandone uno esistente, il momento giusto per definire correttamente l’architettura è prima che il primo cliente enterprise chieda un isolamento dedicato. Contattateci per avviare una conversazione sui requisiti di tenancy della vostra piattaforma.
FAQ
Qual è un esempio di applicazione multi-tenant?
Salesforce è l'esempio più citato: centinaia di migliaia di organizzazioni condividono la stessa infrastruttura applicativa, con l'isolamento dei tenant applicato a livello di accesso ai dati. Shopify segue lo stesso modello per i merchant dell'e-commerce.
Quali sono i principali svantaggi dell'architettura multi-tenant?
I principali svantaggi sono il rischio del vicino rumoroso (il carico di lavoro di un tenant peggiora le prestazioni degli altri), la maggiore complessità applicativa dovuta al filtraggio e al routing consapevoli del tenant e la difficoltà di dimostrare l'isolamento agli auditor della conformità nei modelli a schema condiviso.
Qual è la differenza tra un'architettura single-tenant e multi-tenant?
In un'architettura single-tenant, ogni cliente riceve un'istanza applicativa e un database dedicati. In un'architettura multi-tenant, una singola istanza applicativa serve più clienti, con l'isolamento imposto tramite logica applicativa, separazione degli schemi o confini fisici delle risorse, a seconda del modello scelto.
Cosa significa l’architettura multi-tenant in Salesforce?
Salesforce utilizza un modello di infrastruttura condivisa in cui tutte le organizzazioni clienti operano sulla stessa piattaforma applicativa. L’isolamento dei tenant è garantito da un motore di query proprietario basato sui metadati, che applica automaticamente l’ambito di ogni operazione sui dati all’organizzazione richiedente, rendendo impossibile l’accesso ai dati tra tenant attraverso i normali percorsi applicativi.
Quando si dovrebbe utilizzare un modello a silo invece di un modello pooled?
Utilizza un modello a silo quando un tenant ha requisiti normativi (HIPAA, PCI DSS), obblighi contrattuali di residenza dei dati o impegni SLA aziendali che l’infrastruttura condivisa non può soddisfare in modo affidabile. Per la maggior parte dei clienti SMB o self-service, un modello pooled è l’opzione predefinita più conveniente.