Multi-tenancy ... al contrario di cosa?

Penso che la tua confusione sia tra il termine tecnico "client" (come in client-server) e il business termine "client" (come in, un cliente pagante). La multi-tenancy implica in genere un server che serve più client commerciali , ciascuno con il proprio ambiente separato, utilizzando hardware e software condivisi.

Ad esempio, ho diversi blog Wordpress in esecuzione su una singola istanza del server: c'è solo un processo WP in esecuzione, una sola distribuzione, ma diversi blog definiti, ciascuno con il proprio archivio dati separato (in questo caso, serie di tabelle del database , una comune tecnica multi-tenancy), in modo che ogni proprietario di blog possa gestire solo i propri siti, non sapendo o preoccupandosi che tecnicamente condivida risorse e file con altri blog. Questo è un esempio di un (multi) servizio multi-tenant.

Le sfide tecniche della multi-tenancy includono la sicurezza (come assicurarsi che un tenant non possa vedere i dati di un'altra, un grande no-no), affidabilità e robustezza (come impedire che i bug di un tenant oi plugin tengano giù gli altri , o come prendere un tenant offline o eseguire il backup dei dati senza influire sugli altri), scalabilità (come supportare un numero ampio e dinamico di tenant senza dover migrare l'intero server al nuovo hardware quando ne vengono aggiunti altri) e provisioning (come gestire, estendere, disabilitare e aggiungere nuovi inquilini senza smontare il sistema).

Supponiamo che tu sia un'azienda di software e sviluppi un'applicazione Web personalizzata per un cliente. Lo esegui su un server per loro, e di tanto in tanto ordinano alcune modifiche.

Poi ottieni un altro cliente, vogliono anche la tua applicazione! Con alcune modifiche - i propri loghi e così via, e ovviamente con dati diversi in modo da girare su un database separato. Quindi aggiusti la tua applicazione e installa questa versione su un secondo server.

Più clienti hai, più diventa difficile da controllare.

Alla fine vuoi passare a una applicazione, con l'installazione una , magari usando un database, ma dove i diversi utenti possono ancora solo assolutamente vedere i propri dati. Questa è una versione multi-tenant della tua applicazione.

Ovviamente, se avessi iniziato con l'idea che stavi creando un prodotto per molti clienti, probabilmente avresti progettato la tua applicazione web in quel modo sin dall'inizio. Ma succede molto che qualcosa inizi come software personalizzato per un cliente e solo in seguito si evolva in qualcosa di più grande, quindi passare da "single-tenant" a "multi-tenant" diventa una cosa importante.

La parte importante è "un tenant è un gruppo di utenti che condividono un accesso comune con privilegi specifici all'istanza del software."

Mettiamolo in un esempio di Stack Exchange. Esistono quattro classi principali di utenti: utenti non registrati, utenti, moderatori e personale. Ci sono anche oltre 160 siti nella rete, e un utente può avere un diverso set di permessi su diversi siti - il personale è probabile che sia lo staff ovunque, ma io sono un moderatore qui su Ingegneria del Software, un utente su Stack Overflow e I non sono registrato su una manciata di siti.

In un'istanza multi-tenant, tutti i siti condividono le stesse risorse: gli stessi server Web, le stesse directory di file, gli stessi database e così via. Quindi, ci sarebbe il rilevamento per determinare a cosa ho accesso e qual è il livello di accesso. Ad esempio, il sottodominio può essere utilizzato per caricare il mio livello di accesso dalle credenziali. Tutti i miei record utente sono memorizzati nello stesso database, ma il sottodominio potrebbe essere una chiave per caricare i miei permessi e le mie impostazioni.

In un'istanza single-tenant, tutti i siti avrebbero risorse diverse. Possono condividere una base di codice comune. Possono condividere le stesse risorse fisiche, ma possono avere più database o strutture di directory. Non c'è mescolanza di dati. Nell'esempio Stack Exchange, è possibile distribuire lo stesso codice in 160 directory radice Web e aggiornare 160 schemi di database quando si distribuisce un nuovo codice.