Sfortunatamente, questo termine non ha un buon equivalente in russo. «Wikipedia» fornisce «multi-affitto, affitto multiplo». A volte è chiamato «proprietà multipla». Questi termini possono creare un po' di confusione, poiché l'argomento non è essenzialmente legato all'affitto o alla proprietà. Si tratta di un problema strettamente legato all'architettura del software e all'organizzazione del suo utilizzo. E quest'ultimo aspetto è altrettanto importante.
Abbiamo iniziato a formare la nostra comprensione del multitenancy contemporaneamente all'inizio della progettazione del nostro approccio al modello di lavoro cloud (servizi) di «1C:Enterprise». Questo è accaduto alcuni anni fa. E da allora la nostra comprensione si è ampliata costantemente. Scopriamo continuamente nuovi aspetti (vantaggi, svantaggi, complessità, caratteristiche, ecc.) relativi a questo argomento.
A volte, gli sviluppatori intendono per multitenancy un argomento abbastanza semplice: «per memorizzare i dati di più organizzazioni in un'unica base dati, è necessario aggiungere a tutte le tabelle una colonna con l'identificatore dell'organizzazione e applicare un filtro su di essa». Anche noi, naturalmente, abbiamo iniziato il nostro lavoro su questo argomento da questo punto. Ma abbiamo capito abbastanza rapidamente che si trattava solo di un aspetto (che, per inciso, non è semplice). In realtà, è «un intero paese».
L'idea principale del multitenancy può essere descritta più o meno così. Un'applicazione normale è un cottage progettato per una sola famiglia, che utilizza la sua infrastruttura (pareti, tetto, fornitura d'acqua, riscaldamento, ecc.). Un'applicazione multitenancy è un condominio. In essa, ogni famiglia utilizza la stessa infrastruttura, ma l'infrastruttura è realizzata per l'intero edificio.
E l'approccio multitenancy è positivo o negativo? Si possono trovare opinioni molto diverse su questo. Sembra che non ci sia un «buono o cattivo» in generale. È necessario confrontare vantaggi e svantaggi nel contesto dei compiti specifici da risolvere. Ma questo è un argomento a parte...
Nel senso più semplice, l'obiettivo del multitenancy è ridurre i costi di supporto dell'applicazione attraverso la «socializzazione» dei costi per l'infrastruttura. È un movimento simile alla riduzione dei costi dell'applicazione tramite l'uso di una soluzione standard (forse con personalizzazioni e modifiche), invece di scrivere «su misura». Solo in un caso la progettazione è socializzata, mentre nell'altro è l'operatività.
Inoltre, ripetiamo, qui non c'è un legame diretto con il metodo di vendita. L'architettura multitenancy può essere applicata anche nelle infrastrutture IT aziendali o governative per automatizzare un gran numero di filiali simili e imprese del gruppo.
Si può dire che il multitenancy non sia solo una questione di organizzazione della memorizzazione dei dati. È un modello di funzionamento dell'applicazione nel suo complesso (inclusi aspetti significativi della sua architettura, modello di distribuzione e organizzazione della manutenzione).
La cosa più complessa e interessante del modello multitenancy, a nostro avviso, è che l'essenza dell'applicazione si "duplica". Una parte delle funzionalità lavora con aree di dati specifiche (appartamenti) e "non si interessa" a ciò che avviene nei vari appartamenti. L'altra parte percepisce l'intero edificio e lavora immediatamente per tutti gli inquilini. Tuttavia, quest'ultima non può astrarsi dal fatto che si tratta comunque di appartamenti separati, e è necessario garantire il livello appropriato di granularità e sicurezza.
Nel "1C:Enterprise" il modello multitenancy viene realizzato a livello di diverse tecnologie. Questi sono i meccanismi della piattaforma "1C:Enterprise", i meccanismi di" e "", meccanismi (librerie di sottosistemi standard).
Ognuno di questi elementi contribuisce alla costruzione dell'infrastruttura complessiva di un condominio. Perché viene implementato in diverse tecnologie anziché in una sola, ad esempio nella piattaforma? Prima di tutto perché alcuni meccanismi, a nostro avviso, possono essere modificati in modo appropriato in base al particolare scenario di distribuzione. Ma in generale si tratta di una questione complessa, e ci troviamo costantemente di fronte alla scelta – a quale livello sia meglio implementare un certo aspetto del multitenancy.
È evidente che la parte fondamentale dei meccanismi doveva essere realizzata nella piattaforma. Per esempio, la suddivisione dei dati. Ciò da cui di solito inizia la conversazione sul multitenancy. Ma alla fine, il modello multitenancy ha "colpito" una parte significativa dei meccanismi della piattaforma e ne ha richiesto il miglioramento, e in alcuni casi anche una ripensamento.
A livello di piattaforma abbiamo implementato proprio i meccanismi di base. Questi consentono di creare applicazioni che funzionano nel modello di multitenancy. Ma affinché le applicazioni "vivano e funzionino" in questo modello, è necessario avere un sistema di gestione della loro "vita operativa". A questo si occupano le tecnologie 1cFresh e il layer unificato di logica aziendale a livello di BСП. Proprio come un condominio fornisce ai residenti tutto il necessario, così le tecnologie 1cFresh forniscono tutto ciò di cui hanno bisogno le applicazioni che operano nel modello di multitenancy. E affinché le applicazioni possano interagire con questa infrastruttura (senza sostanziali modifiche), vengono inseriti i corrispondenti "innesti" sotto forma di sottosistemi BСП.
Dal punto di vista dei meccanismi della piattaforma è facile notare che man mano che acquisiamo esperienza e sviluppiamo l'opzione di utilizzo nel cloud di "1C:Enterprise" espandiamo la gamma di meccanismi coinvolti in questa architettura. Facciamo un esempio. Nel modello di multitenancy cambia significativamente la distribuzione dei ruoli tra i partecipanti alla gestione delle applicazioni. Aumenta notevolmente il ruolo (livello di responsabilità) di coloro che sono incaricati dell'operatività delle applicazioni. È diventato necessario per loro avere strumenti di controllo delle applicazioni più potenti. Questo perché gli utenti delle applicazioni (residenti) si fidano innanzitutto del fornitore con cui lavorano. Per questo motivo abbiamo implementato nella versione 8.3 un nuovo . Questo meccanismo consente agli amministratori del fornitore di limitare la libertà dei programmatori di applicazioni al livello di sicurezza necessario - in sostanza, isola il funzionamento dell'applicazione per ogni residente all'interno di specifici confini di "sandbox".
Un interesse notevole è rappresentato dall'architettura per la gestione delle applicazioni che operano in modalità multitenancy (ciò che viene realizzato nelle tecnologie 1cFresh e BSP). Qui, rispetto al modello di distribuzione tradizionale, aumentano in modo significativo i requisiti per l'automazione dei processi di gestione. A tali processi si aggiungono decine: creazione di nuove aree di dati («appartamenti»), aggiornamento delle applicazioni, aggiornamento delle informazioni normative, backup, ecc. E, naturalmente, aumentano i requisiti per il livello di affidabilità e disponibilità. Ad esempio, per garantire un'interazione affidabile tra le applicazioni e i componenti del sistema di gestione, abbiamo implementato una tecnologia di sistema di chiamata asincrona con consegna garantita.
Un aspetto molto delicato è il modo di condividere dati e processi. A prima vista potrebbe sembrare semplice (se a qualcuno sembra). La maggiore complessità sta nel bilancio tra centralizzazione di dati e processi e decentralizzazione. Da un lato, la centralizzazione consente di ridurre i costi (spazio su disco, risorse del processore, sforzi degli amministratori…). Dall'altro lato, limita la libertà degli «abitanti». Questo è esattamente uno dei momenti di «divisione» dell'applicazione, quando il programmatore deve pensare contemporaneamente all'applicazione in senso stretto (che serve un «appartamento») e in senso lato (che serve tutti gli «abitanti»).
Un esempio di tale «dilemma» può essere rappresentato dalle informazioni normative e di riferimento. È comprensibile che ci sia una forte tentazione di renderle comuni a tutti gli «abitanti» della casa. Ciò consente di conservarle in un unico esemplare e aggiornarle contemporaneamente per tutti. Ma può capitare che un abitante abbia bisogno di modifiche specifiche. Stranamente, ma nella pratica questo accade, anche per le informazioni specificate dai regolatori (enti pubblici). Ne deriva una questione complessa: condividere o non condividere? È certamente allettante creare informazioni comuni per tutti e private per chi desidera. Ma questo porta a una realizzazione tutt'altro che semplice. Ma su questo stiamo lavorando...
Un altro esempio è la progettazione dell'implementazione di processi regolari (eseguiti secondo un programma, avviati dal sistema di gestione, ecc.). Da un lato, possono essere implementati per ciascun dominio di dati separatamente. È più semplice e conveniente. Dall'altra parte, una granularità così fine crea un grande carico sul sistema. Per ridurre il carico, è necessario implementare processi condivisi. Ma questi richiedono una pianificazione più attenta.
Naturalmente, si pone una questione molto significativa. Come possono gli sviluppatori di applicazioni garantire il funzionamento in modalità multitenancy? Cosa devono fare al riguardo? Certamente, miriamo a far sì che il peso delle questioni tecnologiche e infrastrutturali ricada il più possibile sulle spalle della tecnologia fornita, mentre lo sviluppatore dell'applicazione dovrebbe concentrarsi solo sugli aspetti della logica aziendale. Ma, come con altre questioni architettoniche importanti, è necessario che gli sviluppatori di applicazioni abbiano una certa comprensione del funzionamento nel modello di multitenancy e che siano necessarie alcuni sforzi durante lo 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 dei confini di condivisione delle informazioni. Ma ci impegniamo a mantenere queste complessità al minimo. Ci sono già esempi di applicazioni implementate.
Un aspetto importante nel contesto dell'implementazione del multitenancy in "1С:Enterprise" è che stiamo creando un modello ibrido, in cui un'applicazione può funzionare sia in modalità multitenancy che in modalità normale. Questo è un compito piuttosto difficile e merita una discussione separata.
Fonte: habr.com
