Multi-tenant

Multi-tenant si riferisce ad una architettura software in cui una sua singola istanza è eseguita da un server ed è fruita da diverse organizzazioni che, ciascuna con le sue peculiarità ambientali che costituiscono concettualmente uno specifico tenant (come in un immobile le cui unità o vani sono affittati a locatari diversi), vedono il servizio ad esse erogato (che sia per esempio l'applicazione, un software, un ambiente, un sistema, uno spazio logico di archiviazione dati, una struttura di rete) come a loro utilizzo esclusivo e, per gli aspetti eventualmente finanziari, ad ognuna di esse rispettivamente fatturato. La multi-tenancy rappresenta il concetto complementare ad un'architettura multi-istanza, nella quale separate istanze del software sono dedicate alle client organization ed in maniera predefinita.
In un'architettura multi-tenant, il relativo strumento di amministrazione è progettato per partizionare virtualmente e dinamicamente i suoi dati e la sua configurazione in modo che ogni client lavori con un'istanza virtuale personalizzata (ambiente dedicato).

Trattandosi di un neologismo legato al campo delle Tecnologie di Informazione e Comunicazione non esiste un corrispettivo italiano per il termine "Tenant". Letteralmente il termine indica un inquilino e nel caso specifico un "co-proprietario", come coloro che acquisiscono il diritto di proprietà di una struttura in un luogo di villeggiatura che utilizzano in periodi diversi dell'anno. In un'accezione formale, può prendere il significato di locatario.

Il concetto potrebbe essere reso in Italiano con "co-proprietario della piattaforma/infrastruttura" facendo riferimento all'utente fisico (tenant) o "piattaforma in co-proprietà" facendo riferimento alla "infrastruttura digitale" (multi-tenancy). O potrebbe rendere l'idea una cosa tipo "architettura condominiale" (ma, come tanti altri termini dell'IT, si utilizza la lingua originale cioè l'inglese).

Adozione

Storia delle applicazioni multitenant

Le applicazioni multitenant si sono evolute da, e combinano alcune caratteristiche, di tre tipi di servizi:

1. Timesharing: Dagli anni '60 le aziende affittavano spazio e potenza di elaborazione sui computer mainframe (time-sharing) per ridurre le spese di calcolo. Spesso hanno anche riutilizzato applicazioni esistenti, con semplicemente un campo di inserimento separato sulla schermata di accesso per specificare un ID dell'account del cliente. Sulla base di questo ID, i contabili del mainframe potevano addebitare ai singoli clienti l'uso di CPU, memoria e disco/nastro effettivamente sostenuto.
2. Applicazioni ospitate: Dagli anni '90 i tradizionali fornitori di servizi applicativi (ASP) ospitavano applicazioni (allora esistenti) per conto dei loro clienti. A seconda delle limitazioni dell'applicazione sottostante, gli ASP erano costretti a ospitare le applicazioni su macchine separate (se più istanze delle applicazioni non potevano essere eseguite nella stessa macchina fisica) o come processi separati. Le applicazioni multitenant rappresentano un'architettura più matura[4] che permette un servizio simile con costi operativi inferiori.
3. Applicazioni web: Applicazioni web popolari orientate al consumatore (come Hotmail) sviluppate con una singola istanza di applicazione che serve tutti i clienti. Le applicazioni multitenant rappresentano un'evoluzione naturale di questo modello, offrendo ulteriore personalizzazione a gruppi di utenti all'interno (diciamo) della stessa organizzazione cliente.

Differenziazione dalla virtualizzazione

In un ambiente multitenancy, più clienti condividono la stessa applicazione, in esecuzione sullo stesso sistema operativo, sullo stesso hardware, con lo stesso meccanismo di archiviazione dei dati. La distinzione tra i clienti è realizzata durante la progettazione dell'applicazione, quindi i clienti non condividono o vedono i dati dell'altro. Nella virtualizzazione invece i componenti sono trasformati, permettendo ad ogni applicazione del cliente di sembrare eseguita su hardware a essa dedicato.

Economia della multitenancy

Risparmi sui costi

La multitenancy permette di risparmiare sui costi al di là delle economie di scala di base ottenibili consolidando le risorse IT in un'unica operazione.[7] Un'istanza di applicazione di solito incorre in una certa quantità di memoria e di overhead di elaborazione che può essere sostanziale quando moltiplicata per molti clienti, specialmente se i clienti sono piccoli. La multitenancy riduce questo overhead distribuendolo su molti clienti. Ulteriori risparmi sui costi possono venire dai costi di licenza del software sottostante (come i sistemi operativi e i sistemi di gestione di database). In parole povere, se si può eseguire tutto su una singola istanza di software, si deve comprare solo una licenza di software. Il risparmio sui costi può essere eclissato dalla difficoltà di scalare la singola istanza al crescere della domanda - aumentare le prestazioni dell'istanza su un singolo server può essere fatto solo comprando hardware più veloce, come CPU veloci, più memoria e sistemi di dischi più veloci, e tipicamente questi costi crescono più velocemente che se il carico fosse diviso tra più server con più o meno la stessa capacità aggregata.[citazione necessaria] Inoltre, lo sviluppo di sistemi multitenant[8] è più complesso, e i test di sicurezza sono più severi a causa del fatto che i dati di più clienti vengono mescolati.

Aggregazione dei dati/estrazione dei dati

Una delle ragioni più convincenti per i venditori/ISV di utilizzare il multitenancy è per i benefici intrinseci di aggregazione dei dati. Invece di raccogliere dati da fonti di dati multiple, con schemi di database potenzialmente diversi, tutti i dati per tutti i clienti sono memorizzati in un unico schema di database. Così, l'esecuzione di query tra i clienti, l'estrazione dei dati e la ricerca di tendenze è molto più semplice. Questa ragione è probabilmente sopravvalutata, poiché uno dei requisiti fondamentali della multitenancy è la necessità di prevenire l'accesso del fornitore di servizi alle informazioni dei clienti (tenant). Inoltre, è comune separare il database operativo dal database di estrazione (di solito a causa delle diverse caratteristiche del carico di lavoro), indebolendo così l'argomento ancora di più.

Complessità

A causa dell'ulteriore complessità di personalizzazione e della necessità di mantenere metadati per inquilino, le applicazioni multitenant richiedono uno sforzo di sviluppo maggiore. Considerazioni come il sequenziamento dei dati basato su vettori, l'infrastruttura di algoritmi crittografabili e le interfacce di controllo virtualizzate devono essere prese in considerazione.[9]

Container e orchestrazione

Nella multitenancy il container e l'orchestrazione dei container sono altri due concetti peculiari.

Astrattamente la logica dei container è un paradigma di distribuzione di modelli di risorse e altri artefatti in una multitenancy.

Il bucket (lett. "secchio") è l'area specializzata per l'archiviazione dei dati.

Gestione dei rilasci

La multitenancy semplifica il processo di gestione dei rilasci. In un processo tradizionale di gestione dei rilasci, i pacchetti che contengono modifiche al codice e al database sono distribuiti alle macchine desktop e/o server dei clienti; nel caso di una singola istanza, questa sarebbe una macchina server per cliente. Questi pacchetti devono poi essere installati su ogni singola macchina. Con il modello multitenant, il pacchetto in genere ha solo bisogno di essere installato su un singolo server. Questo semplifica notevolmente il processo di gestione del rilascio, e la scala non dipende più dal numero di clienti.

Allo stesso tempo, la multitenancy aumenta i rischi e gli impatti inerenti all'applicazione di una nuova versione di rilascio. Poiché c'è una singola istanza del software che serve più tenant, un aggiornamento su questa istanza può causare tempi di inattività per tutti i tenant anche se l'aggiornamento è richiesto e utile per un solo tenant. Inoltre, alcuni bug e problemi risultanti dall'applicazione della nuova release potrebbero manifestarsi nella visione personalizzata dell'applicazione da parte di altri tenant. A causa del possibile tempo di inattività, il momento dell'applicazione della release potrebbe essere limitato a seconda del programma di utilizzo del tempo di più di un inquilino.

Requisiti

Personalizzazione

Alle applicazioni multitenant è tipicamente richiesto di fornire un alto grado di personalizzazione per supportare i bisogni di ogni organizzazione di destinazione. La personalizzazione include tipicamente i seguenti aspetti:

• Branding: permettere a ogni organizzazione di personalizzare il look-and-feel dell'applicazione per abbinare il proprio branding aziendale (spesso indicato come una "pelle" distinta).
• Flusso di lavoro: accomodare le differenze nel flusso di lavoro per essere usato da una vasta gamma di potenziali clienti.
• Estensioni del modello di dati: supportare un modello di dati estensibile per dare ai clienti la possibilità di personalizzare gli elementi di dati gestiti dall'applicazione per soddisfare le loro esigenze specifiche.
• Controllo dell'accesso: lasciare che ogni organizzazione cliente personalizzi indipendentemente i diritti e le restrizioni di accesso per ogni utente.

Qualità del servizio

Ci si aspetta che le applicazioni multitenant forniscano un adeguato isolamento di sicurezza, robustezza e prestazioni[10] tra più tenant, che è fornito dai livelli sottostanti l'applicazione in caso di applicazioni multi-instanza.

Virtualizzazione

I costi di riprogettazione delle applicazioni per la multitenancy possono essere significativi, specialmente per i fornitori di software che continuano ad offrire una versione on-premises single tenant del loro prodotto. Finiscono per essere costretti a supportare due prodotti distinti con tutti i costi che ne derivano.

Una via alternativa sempre più praticabile al multitenancy che elimina la necessità di un cambiamento architettonico significativo è l'uso della tecnologia di virtualizzazione per ospitare più istanze isolate di un'applicazione su uno o più server. Infatti, quando le applicazioni sono riconfezionate come appliance virtuali, la stessa immagine dell'appliance può essere distribuita in luoghi ospitati da ISV, in sede o da terze parti fidate e persino migrata da un sito di distribuzione all'altro nel tempo.