L’hosting cloud multi-tenant è un modello in cui gli stessi server e software servono molti clienti, con isolamento logico tra i tenant. Vale l’immagine del condominio: gli appartamenti condividono struttura, impianto idraulico ed elettricità, ma ogni porta ha la sua chiave. L’alternativa – l’hosting single-tenant – è una casa indipendente: controllo totale, affitto più alto e una quota di manutenzione più grande che resta in capo a chi la abita.
Punti chiave
| Domanda | Risposta |
|---|---|
| Che cos’è | Server e software condivisi, molti clienti, dati separati logicamente |
| Perché esiste | Condividere l’infrastruttura è ciò che rende possibili i prezzi del cloud |
| La parte difficile | L’isolamento – un tenant non deve mai vedere i dati degli altri né sentirne il carico |
| vs. single-tenant | Più economico, onboarding più rapido, un solo ciclo di aggiornamenti – al prezzo della separazione fisica |
| Dove va l’isolamento | Nel livello dati – non nella clausola WHERE di ogni query |
Come restano separati i dati dei tenant
Ogni sistema multi-tenant risponde prima di tutto a una domanda: dove vive l’isolamento? A livello di database esistono tre pattern canonici – schema condiviso, uno schema per tenant e un database per tenant. Lo schema condiviso è il cavallo da tiro, ed è più sicuro quando è il database stesso a imporre il confine:
-- Modello 1: schema condiviso – ogni riga porta il suo tenant
CREATE TABLE invoices (
id bigserial PRIMARY KEY,
tenant_id uuid NOT NULL,
amount numeric(10,2) NOT NULL
);
-- L'isolamento si impone nel database, non in ogni query
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id')::uuid);Con una policy a livello di riga, una query che dimentica il filtro del tenant non restituisce nulla invece di restituire tutto – la modalità di guasto passa dalla fuga di dati alla pagina vuota.
Su un Backend as a Service lo stesso principio si esprime come controllo degli accessi per oggetto anziché come policy SQL. Ogni record porta una ACL che nomina il ruolo del tenant autorizzato a vederlo, e la piattaforma la impone a ogni richiesta:
// JavaScript / Node.js — Back4app JS SDK
const doc = new Parse.Object('Invoice');
doc.set('amount', 480);
const acl = new Parse.ACL();
acl.setPublicReadAccess(false); // invisible to every other tenant
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// Flutter / Dart — Back4app Flutter SDK
final doc = ParseObject('Invoice')..set('amount', 480);
final acl = ParseACL();
acl.setPublicReadAccess(allowed: false);
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// iOS / Swift — Back4app Swift SDK
var doc = Invoice()
doc.amount = 480
var acl = ParseACL()
acl.publicRead = false
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
doc.ACL = acl
doc.save { _ in }// Android / Kotlin — Back4app Android SDK
val doc = ParseObject("Invoice").apply { put("amount", 480) }
val acl = ParseACL().apply {
publicReadAccess = false
setRoleReadAccess("tenant-acme", true)
setRoleWriteAccess("tenant-acme", true)
}
doc.acl = acl
doc.saveInBackground()L’isolamento è uno spettro, non un interruttore
Tra “tutto condiviso” e “tutto dedicato” stanno le tre forme di deployment tra cui sceglie la maggior parte dei sistemi reali:
Le piattaforme mature li combinano: pool per i molti tenant piccoli, bridge per quelli di taglia media, silo per i pochi che sono regolamentati, enormi o rumorosi. L’errore è trattare la scelta come globale – si può fare per fascia di offerta, e anche per singolo componente.
Hosting multi-tenant vs. single-tenant
| Dimensione | Multi-tenant | Single-tenant |
|---|---|---|
| Costo per tenant | Basso – l’infrastruttura è ammortizzata | Alto – stack dedicato per cliente |
| Isolamento dei dati | Logico (policy, ACL, schemi) | Fisico (istanza e database separati) |
| Raggio d’impatto | Un incidente può toccare molti tenant | Circoscritto a un solo cliente |
| Noisy neighbor | Possibile; richiede quote e throttling | Assente – le risorse sono private |
| Aggiornamenti | Un solo rollout aggiorna tutti | Ogni istanza va patchata separatamente |
| Onboarding | Modifica di configurazione, minuti | Provisioning, da ore a settimane |
| Personalizzazione | Configurazione e feature flag | Modifiche profonde, possibili per istanza |
| Aderenza alla compliance | Adeguata nella maggior parte dei casi; attriti sotto regimi severi | Preferito dove l’isolamento stretto è un obbligo |
| Uso tipico | SaaS, BaaS, piattaforme cloud condivise | Settori regolamentati, fasce enterprise premium |
Due significati da tenere distinti
“Hosting cloud multi-tenant” si usa a due altitudini diverse, e gran parte delle spiegazioni le confonde:
- Come fascia di hosting: l’hosting condiviso – il proprio carico di lavoro gira sulle stesse macchine fisiche di quelli di altri clienti. È la modalità predefinita di ogni cloud pubblico; la definizione del NIST elenca il pooling delle risorse tra tenant come caratteristica essenziale del cloud computing stesso.
- Come architettura applicativa: il proprio prodotto serve i suoi clienti da un unico backend condiviso – il modo in cui si costruisce il software in abbonamento. Qui il padrone di casa è chi sviluppa, e l’isolamento dei tenant diventa una sua responsabilità: è il punto in cui entrano in gioco i pattern descritti sopra.
I due si compongono: un prodotto SaaS – multi-tenancy, cioè la condivisione di una stessa istanza tra più tenant, a livello applicativo – gira di norma su infrastruttura cloud condivisa, multi-tenancy a livello di hosting, e ogni livello isola i propri tenant.
Il problema del noisy neighbor
Condividere significa contesa: l’importazione massiva di un tenant può rallentare il checkout di un altro. Le contromisure standard, in ordine crescente:
- Quote e rate limiting per tenant – mettere un tetto a quanto ogni tenant può consumare per finestra temporale.
- Scheduling delle risorse e autoscaling – assorbire i picchi prima che diventino la latenza di qualcun altro.
- Separazione dei carichi di lavoro – spostare i job pesanti (export, analytics) su code in background, fuori dal percorso della richiesta.
- Siloing parziale – quando un tenant gira costantemente a pieno regime, dare al componente in contesa (di norma il database) una partizione propria e lasciare il resto in pool.
Casi d’uso tipici
- Prodotti SaaS. Ogni app in abbonamento che serve tutti i clienti da un’unica codebase – il caso canonico, e la ragione per cui il pattern esiste.
- BaaS e hosting di piattaforma. Le piattaforme fanno girare migliaia di app su infrastruttura condivisa e isolata, così che il provisioning di ogni app costi quasi nulla – è il modello dietro le offerte gratuite.
- Applicazioni B2B con spazi di lavoro per tenant. Un solo deployment, molte organizzazioni clienti, ciascuna con i propri utenti, ruoli e confine dei dati.
- Piattaforme interne. Un unico deployment di analytics o di strumenti condiviso tra i reparti, isolato per team.
- Agenzie che gestiscono molte app per i clienti. Piattaforma condivisa sotto, un backend isolato per cliente sopra.
Multi-tenant, single-tenant o misto? Matrice decisionale
| Scegliere multi-tenant quando… | Scegliere single-tenant quando… | Scegliere il misto quando… |
|---|---|---|
| Si servono molti clienti con un unico prodotto | Normative o contratti impongono l’isolamento fisico | La maggior parte dei tenant è standard, pochi sono regolamentati |
| Il costo per cliente deve tendere a zero | L’SLA di un cliente giustifica capacità dedicata | Un tenant è 100× più grande della mediana |
| Serve un solo ciclo di aggiornamenti per tutti | La personalizzazione profonda per cliente è il prodotto | Serve una fascia di prezzo premium “dedicata” |
| L’onboarding deve essere self-service e istantaneo | I clienti si contano sulle dita di una mano | Un tenant rumoroso ha bisogno di un database proprio |
Conviene partire dal multi-tenant e guadagnarsi l’uscita un tenant alla volta – innestare la tenancy a posteriori su una codebase single-tenant è molto più difficile che mettere in silo, più avanti, un singolo cliente troppo esigente.
Limiti e trade-off
- L’isolamento vale quanto la sua applicazione. Un filtro di tenant dimenticato nel codice applicativo è la classica fuga di dati tra tenant. Il confine va spinto nel livello dati – policy a livello di riga, ACL per oggetto – così che la piattaforma fallisca in modo chiuso.
- Raggio d’impatto condiviso. Un disservizio, un deployment sbagliato o una violazione possono colpire tutti i tenant insieme. I rollout a scaglioni e i backup per tenant riducono l’impatto, non la condivisione.
- I noisy neighbor sono strutturali. Quote e scheduling gestiscono la contesa; solo il siloing parziale la elimina, ai prezzi di un silo parziale.
- Tetto alla personalizzazione. I tenant condividono un’unica codebase, quindi il comportamento specifico di ciascuno vive nella configurazione e nei feature flag – un vincolo che i clienti single-tenant non hanno.
- Contesto del tenant in ogni punto. Ogni query, chiave di cache, job e riga di log deve conoscere il tenant; la complessità si sposta dall’infrastruttura all’applicazione, ed è esattamente il peso che l’isolamento gestito nel livello dati esiste per assorbire.
L’hosting multi-tenant su Back4app
Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È multi-tenant a entrambe le altitudini. Come piattaforma, fa girare migliaia di backend applicativi isolati su infrastruttura condivisa – è la ragione per cui il provisioning di un nuovo backend richiede pochi minuti sull’offerta gratuita. Per i tenant dell’applicazione di chi sviluppa, l’isolamento è una feature del livello dati e non una convenzione: ogni oggetto porta una ACL, i ruoli raggruppano gli utenti per tenant e i permessi di classe fissano regole valide per tutto lo schema, tutto imposto da Back4app a ogni richiesta. L’approfondimento tecnico sulla sicurezza a livello di riga mostra il pattern completo su un database documentale – senza richiedere alcuna disciplina sulla clausola WHERE.
Domande frequenti
Che cos'è la multi-tenancy nel cloud computing?
Un'architettura in cui una singola istanza software – e l'infrastruttura che la sostiene – serve più clienti, chiamati tenant. I tenant condividono calcolo, archiviazione e una stessa codebase, ma i dati di ciascuno sono isolati logicamente e invisibili agli altri. È il modello che fa funzionare l'economia del cloud: aggiungere un cliente è una modifica di configurazione, non hardware in più.
Qual è la differenza tra hosting multi-tenant e single-tenant?
Il single-tenant assegna a ogni cliente un'istanza e un database dedicati – controllo massimo e isolamento fisico, a un prezzo più alto, con ogni istanza patchata e aggiornata separatamente. Il multi-tenant condivide un'unica istanza tra tutti i clienti – costo per tenant più basso, un solo ciclo di aggiornamenti per tutti e isolamento imposto in modo logico anziché fisico. La maggior parte dei SaaS gira in multi-tenant; i clienti regolamentati o molto grandi a volte giustificano il single-tenant.
Un cloud multi-tenant è sicuro?
Sì, quando l'isolamento è imposto correttamente – i tenant non possono vedere i dati degli altri. I rischi residui sono i bug applicativi che saltano un filtro di tenant e il raggio d'impatto più ampio di un sistema condiviso: una violazione o un disservizio può toccare ogni tenant. Per questo i progetti più solidi spingono l'isolamento fino al livello dati – policy a livello di riga e controllo degli accessi per oggetto – invece di affidarsi al fatto che ogni query si ricordi la clausola WHERE.
Che cos'è il problema del noisy neighbor?
L'uso intensivo di CPU, memoria o I/O condivisi da parte di un tenant, che degrada le prestazioni di tutti gli altri sulla stessa infrastruttura. Le contromisure comprendono quote e rate limiting per tenant, lo scheduling delle risorse, l'autoscaling e – quando un tenant gira costantemente a pieno regime – il partizionamento del componente in contesa, di norma il database, in un silo proprio.
Come si tengono separati i dati dei tenant in un cloud condiviso?
A livello di database esistono tre pattern canonici: uno schema condiviso in cui ogni riga porta un identificatore di tenant (densità massima, di norma abbinato alla sicurezza a livello di riga), uno schema per tenant in un database condiviso e un database per tenant (isolamento più forte, costo più alto). Sotto, l'infrastruttura aggiunge i propri livelli: macchine virtuali, namespace dei container e micro-VM tengono separati i carichi di lavoro dei tenant.
La multi-tenancy è la stessa cosa della virtualizzazione?
No. La virtualizzazione divide una macchina fisica in macchine virtuali isolate; la multi-tenancy condivide una singola istanza applicativa tra molti clienti. Le due sono complementari – la virtualizzazione è uno dei meccanismi con cui i provider isolano i carichi di lavoro dei tenant, mentre la multi-tenancy è il pattern architetturale che decide, a monte, che cosa viene condiviso.
Quando conviene scegliere invece il single-tenant?
Quando regimi normativi severi o contratti impongono l'isolamento fisico o la residenza dei dati, quando un cliente ha bisogno di una personalizzazione profonda per istanza, o quando le prestazioni garantite per un account di alto valore contano più del costo. La risposta sempre più diffusa è la tenancy mista: mettere in pool la maggior parte dei tenant su infrastruttura condivisa e in silo i pochi che sono regolamentati, enormi o rumorosi.
Perché la multi-tenancy conta per il SaaS?
È l'architettura su cui si regge il software in abbonamento. Un'unica codebase serve ogni cliente, così correzioni e funzionalità arrivano a tutti i tenant nello stesso momento; l'utilizzo dell'hardware si distribuisce su tutta la base clienti; e l'onboarding di un nuovo cliente costa quasi nulla. Senza multi-tenancy, ogni abbonamento porterebbe il prezzo di server dedicati e di una manutenzione per singolo cliente.