Multi tenancy o multiistanza?

Sto cercando di creare una soluzione SaaS basata sul Web e ho intrapreso una strada in cui non sono sicuro di utilizzare la multi-tenancy o la multiistanza. Proverò a descrivere ciò che sto cercando di ottenere e ogni approccio presenta vantaggi e svantaggi (la mia opinione, secondo quanto ho letto). Ti preghiamo di includere i tuoi suggerimenti nel caso in cui avessi perso qualcosa in un approccio rispetto all'altro.

L'applicazione che sto cercando di creare è, come ho già detto, una soluzione SaaS in cui le aziende possono creare i propri account e ogni account / azienda ha i propri utenti, clienti, prodotti, servizi ... ecc. Ogni utente; chi è un dipendente dell'azienda; relativi a un account / azienda avranno accesso solo ai clienti, ai prodotti e ai servizi dell'azienda. Le aziende potrebbero avere un numero illimitato di clienti, prodotti e servizi, quindi ogni azienda dovrebbe avere il proprio data center.

Per questo ho deciso di creare un database condiviso (salvando tutte le credenziali degli utenti ai fini del login) e lo schema condiviso di più database (database per account / azienda). Fondamentalmente, multi-locazione .

Quindi qualcuno ha suggerito di usare invece Multi Instance , dove ogni azienda avrà la propria istanza dell'applicazione (cioè codice, librerie, database, framework ... ecc.) Totalmente separata dalle altre società. Suona meglio perché non devo occuparmi di un livello aggiuntivo in cui devo assicurarmi che gli utenti di ciascun inquilino abbiano accesso solo ai dati della loro azienda. Penso che sia bello ricordare che dipendo da Docker per raggiungere questo approccio (non l'ho mai usato prima), ma penso che manchi di funzionalità (più su quelle successive) di cui avrò bisogno in futuro (almeno non l'ho fatto li trovi con un po 'di ricerca).

Tuttavia, ogni approccio presenta vantaggi e svantaggi, quindi non ho potuto decidere quale approccio seguire. Ecco un elenco, ma nudo con me poiché non ho la conoscenza di entrambi, quindi potrebbe esserci qualcosa di cui non sono a conoscenza, o una soluzione per un problema che non ho trovato sul web: [Ogni approccio ha un elenco ordinato di cui ho seguito uno a uno di confronto]

Locazione multipla :

1. Host / hardware condiviso, codice condiviso e multi database.
2. È più semplice estendere la funzionalità del codice e correggere i bug (codice condiviso).
3. È più difficile estendere l'hardware (potrebbe utilizzare un servizio cloud) o spostare il database del singolo tenant su un altro sistema senza apportare modifiche al codice.
4. Ancora più importante, come ho detto prima, devo aggiungere un ulteriore livello al sistema per assicurarmi che l'utente appartenga effettivamente alla sua azienda e non acceda alle informazioni di altre società.

Istanza multipla :

1. Host / hardware condiviso o non condiviso, codice per istanza e database per istanza.
2. È più difficile estendere la funzionalità o correggere i bug (non sono sicuro che ci sia un modo per farlo in Docker in cui è possibile aggiungere funzionalità / funzionalità a un'istanza o contenitore Docker e distribuirlo agli altri).
3. È più semplice spostare l'intera istanza su un host / hardware diverso.
4. Come istanza, non ho bisogno di occuparmi di quel livello poiché ogni istanza avrà il suo database.

Tutti i vantaggi e gli svantaggi sono ridondanti nel caso in cui io voglia fare qualcosa manualmente (come la creazione manuale di un'istanza per ciascun inquilino), ed è per questo che dubito della soluzione Docker, a meno che non ci sia un modo per risolverlo, che è forse il principale ragione della domanda. Ti sarei grato se rispondessi alla domanda con riferimenti alle soluzioni e perché pensi che questo approccio sia migliore dell'altro.

Nel caso ciò possa aiutare (forse?), Stiamo usando Laravel come framework principale per il back-end (tutto RESTfully).

Mi sto ponendo la stessa identica domanda al momento.

Mi sto orientando verso la soluzione di locazione singola multiistanza ma non ho ancora preso una decisione definitiva. Vorrei condividere alcuni dei miei pensieri:

Il principale vantaggio storico dell'architettura multi-tenant è un migliore utilizzo delle risorse dell'infrastruttura , attraverso la mutualizzazione (sistema operativo singolo, singolo database, singolo livello di applicazione) e una migliore occupazione di tali risorse (quando un utente è assente, un altro può utilizzare la stessa risorsa) .

Inoltre semplifica notevolmente il ciclo di vita del software : distribuisci nuove versioni su una sola istanza, tutti i clienti vengono aggiornati contemporaneamente.

Sembra tuttavia che i recenti progressi nella tecnologia cloud rendano la prima classe di vantaggi ampiamente disponibile in un'architettura multiistanza (istanza per cliente) (sto pensando specificamente a una piattaforma come Jelastic qui, ma sono sicuro che ce ne sono altri che fornire le stesse funzionalità):

• PaaS basato su container
• Provisioning e ridimensionamento automatico dei contenitori (contenitori elastici)

Quindi la gestione dell'hardware e della piattaforma non è più una preoccupazione del fornitore del software. Le risorse sono reciprocizzate in modo molto più efficiente rispetto a prima a livello di infrastruttura e piattaforma .

Ci sarà comunque un sovraccarico per l'istanza multipla (alcune app e middleware verranno eseguiti N volte invece di una sola), ma molto più bassi rispetto a quando si utilizza una macchina (virtuale) separata per istanza. Il database può essere condiviso comunque (uno schema per istanza, diversi schemi per server DB)

Anche :

• L'automazione della creazione di nuove istanze è possibile tramite l'API PaaS
• L'automazione della distribuzione di nuove versioni è possibile tramite l'API PaaS, con tempi di inattività pari a zero (richiede un po 'di lavoro per essere implementata)
• Il ridimensionamento è sempre fuori, mai in alto. Non dobbiamo preoccuparci di enormi set di dati a livello di istanza.

Certo, avremmo bisogno di un qualche tipo di servizio centrale che gestisca tutto questo automaticamente (ad esempio la creazione di un'istanza quando un nuovo utente crea un account). Ciò gestirà anche problemi di pagamento e di licenza, interazione tra istanze ecc. Questo servizio centrale potrebbe essere piuttosto complesso e difficile da sviluppare, ma il bello è che non dobbiamo implementarlo in anticipo (ora che non abbiamo molto risorsa) mentre il multi-tenant dovrebbe essere inserito nell'app fin dall'inizio.

Il che mi porta ai vantaggi finali dello sviluppo di single-tenant per un progetto di avvio molto precoce (pre-invesment):

• La stessa (o quasi) versione dell'app può essere distribuita in locale come appliance virtuale o contenitore docker o persino su una macchina gestita dal cliente (alcune società sono ancora riluttanti verso il cloud e potrebbe aiutare un avvio iniziale a non estromettere i primi utenti importanti)
• Più veloce per ottenere un prodotto con risorse limitate (il livello dell'applicazione e lo schema del database è piuttosto meno complesso), può ottenere prima un prodotto "stupido" a singolo tenant a istanza singola (MVP) per i primi utenti e mostrare il valore aziendale dell'app ai potenziali investitori e aggiungere successivamente tutta l'automazione del cloud
• Può essere visto come un argomento di vendita per i clienti preoccupati per la sicurezza dei dati: i dati sono meglio incapsulati poiché ogni cliente ha il proprio schema o addirittura database. Molto meno rischio di "fuoriuscita"

NB: sto ovviamente pensando a un'app aziendale in cui i clienti sarebbero aziende (ciascuna con più utenti singoli) e non singoli. Non avrebbe senso eseguire un'istanza separata di un'app per ogni singolo utente (o sarebbe?)

È anche possibile supportare entrambe le opzioni (un pool di tenant in più istanze).

Prediligo la causa multiistanza dell'isolamento naturale. L'istanza di ogni cliente viene eseguita nei propri processi e i suoi dati sono isolati nel proprio database. Se lo si desidera, è possibile aggiornare le istanze a nuove versioni in base al cliente / istanza.

I sistemi basati su titolari presentano un rischio per la sicurezza delle informazioni. Considera solo quanto è facile dimenticare una clausola "WHERE tenantId = x". Il motivo principale per utilizzare un sistema compatibile con gli inquilini sarebbe la prestazione, i processi sono pesanti, condividendo un processo è possibile ottenere di più da una macchina. Questo era più vero, penso in un mondo a 32 bit, quindi oggi è su macchine a 64 bit che hanno molta più RAM.

Un sistema a più istanze avrebbe forse bisogno di un po 'più di strumenti per creare e configurare l'ambiente come database e istanze di applicazioni web. Si può sostenere che è necessario disporre di questo script in ogni caso anche per le distribuzioni a singola istanza. Questo ha anche altri vantaggi come la possibilità di impostare ambienti di sviluppo e test

Lascerei fuori le capacità degli inquilini fino a quando non ne avrai la possibilità (costo di ingegneria contro denaro risparmiato sull'infrastruttura (hardware) attraverso la condivisione dei processi).