Sfortunatamente, non esiste un buon equivalente in lingua russa per questo termine. Wikipedia fornisce «multi-tenancy, affitto multiplo». A volte viene definito «proprietà multipla». Questi termini possono essere un po' fuorvianti, poiché l'argomento non è in realtà legato né all'affitto né alla proprietà. Si tratta di un tema legato all'architettura del software e alla sua gestione. Quest'ultima, tra l'altro, è altrettanto importante.
Abbiamo iniziato a formare la nostra comprensione del multitenancy mentre progettavamo l'approccio al modello di lavoro cloud (servizio) di «1C:Enterprise». È stata qualche anno fa. E da allora la nostra comprensione è in continua espansione. Scopriamo costantemente nuovi aspetti (vantaggi, svantaggi, complessità, peculiarità, ecc.) di questo argomento.
A volte gli sviluppatori intendono per multitenancy un concetto piuttosto semplice: «per conservare i dati di diverse organizzazioni in un unico database, è necessario aggiungere una colonna con l'identificatore dell'organizzazione a tutte le tabelle e imporre un filtro su di essa». Naturalmente, anche noi abbiamo iniziato la nostra indagine da questo punto. Tuttavia, ci siamo resi conto abbastanza rapidamente che questo è solo un aspetto (anch'esso non semplice). In realtà, si tratta di un «intero paese».
L'idea principale del multitenancy può essere descritta all'incirca in questo modo. Un'applicazione normale è una villa progettata per una sola famiglia, che utilizza la sua infrastruttura (pareti, tetto, approvvigionamento idrico, riscaldamento, ecc.). Un'applicazione multitenancy, invece, è un condominio. In esso, ogni famiglia utilizza la stessa infrastruttura, ma quest'ultima è realizzata per l'intero edificio.
È un approccio multitenancy buono o cattivo? Puoi trovare opinioni molto diverse su questo tema. Sembra che non ci sia un concetto di «buono o cattivo» in senso assoluto. Bisogna confrontare vantaggi e svantaggi nel contesto delle specifiche problematiche da risolvere. Ma questo è un argomento separato…
In termini semplici, l'obiettivo del multitenancy è ridurre i costi di mantenimento dell'applicazione attraverso la «socializzazione» delle spese per l'infrastruttura. È un movimento simile a quello di abbattere i costi dell'applicazione attraverso soluzioni standardizzate (possibilmente con personalizzazioni e modifiche), piuttosto che attraverso uno sviluppo «su misura». In un caso, si socializza lo sviluppo, nell'altro la gestione.
Dobbiamo ribadire che qui non c'è un legame diretto con il metodo di vendita. L'architettura del multitenancy può essere utilizzata anche nelle infrastrutture IT aziendali o dipartimentali per automatizzare un gran numero di filiali o imprese affiliate.
Si può dire che il multitenancy non è semplicemente una questione di organizzazione della conservazione dei dati. È un modello di funzionamento dell'applicazione nel suo complesso (compresa una parte significativa degli aspetti della sua architettura, del modello di distribuzione e dell'organizzazione della manutenzione).
La cosa più complessa e interessante del modello multitenancy, a nostro avviso, è che l'essenza dell'applicazione viene «scissa». Parte della funzionalità lavora con aree dati specifiche (appartamenti) e «non si interessa» agli inquilini di altri appartamenti. Un'altra parte percepisce l'intero edificio e lavora contemporaneamente per tutti gli inquilini. Tuttavia, quest'ultima non può astrarsi dal fatto che ci sono effettivamente appartamenti separati, e è necessario garantire un livello di granularità e sicurezza adeguato.
Nel «1C:Enterprise», il modello multitenancy viene implementato a diversi livelli tecnologici. Ci sono meccanismi della piattaforma «1C:Enterprise», meccanismi di» e «», meccanismi (librerie di sistemi standard).
Ciascuno di questi aspetti contribuisce alla costruzione dell'infrastruttura complessiva del condominio. Perché realizzarlo tramite diverse tecnologie anziché in una sola, come la piattaforma? Principalmente perché una parte dei meccanismi, a nostro avviso, può essere modificata in base alla specifica variante di distribuzione. Ma in termini generali, questo è un argomento complesso e ci troviamo costantemente di fronte alla scelta del livello migliore per implementare un dato aspetto del multitenancy.
È evidente che la parte fondamentale dei meccanismi doveva essere implementata nella piattaforma. Ad esempio, la suddivisione dei dati in sé. È solitamente da qui che si comincia a parlare di multitenancy. Tuttavia, alla fine il modello di multitenancy ha coinvolto una parte significativa dei meccanismi della piattaforma, richiedendo il loro miglioramento e, in alcuni casi, una revisione.
A livello di piattaforma, abbiamo implementato i meccanismi di base. Questi consentono di creare applicazioni che operano secondo il modello multitenancy. Tuttavia, affinché le applicazioni 'vivano e funzionino' in questo modello, è necessario avere un sistema di gestione della loro 'vita operativa'. Questo è garantito dalle tecnologie 1cFresh e dal livello unificato della logica aziendale a livello di BSP. Così come in un condominio l'infrastruttura fornisce ai residenti tutto il necessario, le tecnologie 1cFresh forniscono tutto il necessario alle applicazioni che operano nel modello multitenancy. E affinché le applicazioni possano interagire con questa infrastruttura (senza dover apportare significativi miglioramenti), vengono inseriti i corrispondenti 'connettori' sotto forma di sottosistemi BSP.
Dal punto di vista dei meccanismi della piattaforma, è facile notare che man mano che acquisiamo esperienza e sviluppiamo l'uso cloud di '1C:Enterprise', ampliamo il insieme dei meccanismi coinvolti in questa architettura. Facciamo un esempio. Nel modello multitenancy cambia significativamente la distribuzione dei ruoli tra i partecipanti alla gestione delle applicazioni. Aumenta notevolmente il ruolo (il livello di responsabilità) di coloro che si occupano dell'esercizio delle applicazioni. È diventato necessario disporre di strumenti di controllo delle applicazioni più potenti. Perché gli utenti delle applicazioni (residenti) si fidano prima di tutto del fornitore con cui lavorano. Per questo abbiamo implementato nella versione 8.3 un nuovo . Questo meccanismo consente agli amministratori del fornitore di limitare la libertà degli sviluppatori di applicazioni al livello necessario di sicurezza – in sostanza, isolare il lavoro dell'applicazione per ogni residente all'interno di determinati limiti di una 'sandbox'.
Anche l'architettura per la gestione delle applicazioni che operano in modalità multitenancy (ciò che viene realizzato con le tecnologie 1cFresh e BSP) è di grande interesse. Qui, rispetto al modello di distribuzione standard, aumentano notevolmente i requisiti per l'automazione dei processi di gestione. Questi processi sono decine: creazione di nuove aree dati ('appartamenti'), aggiornamento delle applicazioni, aggiornamento delle informazioni normative, backup, ecc. E, naturalmente, aumentano le esigenze riguardo al livello di affidabilità e disponibilità. Ad esempio, per garantire una interazione affidabile delle applicazioni con i componenti del sistema di gestione, abbiamo implementato una tecnologia di sistema di chiamate asincrone con consegna garantita.
Un aspetto molto delicato è il modo di rendere comuni dati e processi. Sembra semplice (se a qualcuno sembra) solo a prima vista. La maggiore complessità sta nel bilanciare centralizzazione e decentralizzazione di dati e processi. Da un lato, la centralizzazione consente di ridurre i costi (spazio su disco, risorse di CPU, sforzi degli amministratori…). Dall'altro, limita la libertà dei 'residenti'. Questo è proprio uno dei momenti di 'sdoppiamento' dell'applicazione, in cui lo sviluppatore deve pensare contemporaneamente all'applicazione in senso stretto (che serve un'unica 'appartamento') e in senso ampio (che serve tutti i 'residenti' contemporaneamente).
Come esempio di tale 'dilemma', possiamo citare le informazioni normative e di riferimento. Naturalmente, c'è una grande tentazione di renderle comuni per tutti i 'residenti' del palazzo. Questo consente di conservarle in un'unica copia e di aggiornarle immediatamente per tutti. Ma a volte un certo residente ha bisogno di modifiche specifiche. Stranamente, ma nella pratica ciò accade, anche per informazioni che sono specificate dai regolatori (da enti governativi). Si pone così una questione complessa: rendere comuni o meno? È sicuramente allettante fornire informazioni generali per tutti e private per quelli che ne hanno bisogno. Ma questo conduce a un'implementazione piuttosto complicata. Stiamo lavorando su questo…
Un altro esempio è la progettazione di processi regolari (eseguiti secondo un programma, avviati dal sistema di gestione, ecc.). Da un lato, è possibile implementarle separatamente per ogni area dati. Questo è più semplice e conveniente. Dall'altro, una tale granularità fine crea un carico maggiore sul sistema. Per ridurre il carico, è necessario implementare processi comunitari. Ma richiedono una pianificazione più accurata.
Ovviamente, sorge una domanda piuttosto rilevante. Come possono gli sviluppatori di applicazioni garantire il funzionamento in modalità multitenancy? Cosa devono fare al riguardo? Naturalmente, ci impegniamo a garantire che il peso delle questioni tecnologiche e infrastrutturali ricada il più possibile sulla tecnologia fornita, mentre lo sviluppatore dell'applicazione dovrebbe concentrarsi solo sulle questioni di logica aziendale. Tuttavia, come per altre importanti questioni architettoniche, è necessario che gli sviluppatori di applicazioni abbiano una certa comprensione del funzionamento della modalità multitenancy e che siano richiesti alcuni sforzi nello sviluppo delle applicazioni. Perché? Perché ci sono aspetti che la tecnologia non può garantire automaticamente senza considerare la semantica dei dati. Ad esempio, la definizione stessa dei confini della condivisione delle informazioni. Ci sforziamo, però, affinché queste complessità siano minime. Ci sono già esempi di implementazione di tali applicazioni.
Un aspetto importante nel contesto dell'implementazione della multitenancy in «1C:Enterprise» è che stiamo creando un modello ibrido, in cui un'applicazione può funzionare sia in modalità multitenancy che in modalità standard. Questo è un compito piuttosto complesso e merita una discussione a parte.
Fonte: habr.com
