Multi tenancy o multiistanza?

Question

Sto provando a creare una soluzione SaaS basata sul Web e ho trovato una strada in cui non sono sicuro di utilizzare multi tenancy o multiistanza. Cercherò di descrivere quello che sto cercando di ottenere, e ogni approccio vantaggi e svantaggi (secondo me, secondo ciò che ho letto). Per favore includi i tuoi suggerimenti nel caso in cui mi sia sfuggito qualcosa in un approccio rispetto all'altro.

L'applicazione che sto cercando di creare è, come ho 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 della società; relativo a un account/azienda avrà accesso solo ai suoi clienti, prodotti e servizi. 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 a scopo di accesso) e più database schema condiviso (database per account/azienda). Fondamentalmente, Multi Tenancy.

Poi qualcuno ha suggerito di utilizzare Multi grado invece, in cui ogni azienda avrà una propria istanza dell'applicazione (vale a dire il codice, librerie, database, quadri, ecc ...) totalmente separato dalle altre aziende. Questo suona meglio in quanto non devo occuparmi di un ulteriore livello in cui ho bisogno di assicurarmi che gli utenti di ciascun inquilino abbiano accesso solo ai dati della loro azienda. Penso che sia bello dire che sto dipendendo 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 li ho trovati con un po 'di ricerca).

Tuttavia, ogni approccio ha pro e contro, quindi non ho potuto decidere con quale approccio andare. Ecco una lista, ma nuda con me perché mi manca 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 un uno per uno confronto]

multi tenancy:

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

Multi Instance:

1. concorrente o non condivisa host/hardware, il codice per esempio, e il database per istanza.
2. È più rigido per estendere la funzionalità o correggere i bug (non sono sicuro se c'è un modo per farlo in Docker dove è possibile aggiungere funzionalità/funzionalità a un'istanza o contenitore Docker e distribuirlo agli altri).
3. È più semplice per 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 proprio database.

Tutti i vantaggi e gli svantaggi sono ridondanti nel caso in cui voglio fare nulla manualmente (come la creazione di un'istanza per ogni inquilino manualmente), ed è per questo dubito che la soluzione Docker, a meno che non ci sia un modo per risolvere questo , che è forse la ragione principale della domanda. Gradirei se rispondessi alla domanda con riferimenti alle soluzioni e perché pensi che questo approccio sia migliore dell'altro.

Nel caso che sarebbe di aiuto (forse?), Stiamo usando Laravel come il quadro principale per il back-end (tutto RESTfully).

Answer 1

Altri hanno avuto questi problemi prima. Per esempio. c'è sth. là fuori chiamato il SaaS Maturity Model. Penso che i modelli di maggior successo siano nati prima con la funzionalità, e la piattaforma come preoccupazione secondaria. Quindi vorrei prima passare un'istanza per strategia del cliente. Comunque quanti clienti ci saranno all'inizio? È più probabile che fallisca perché al cliente non piace la funzionalità o perché stai utilizzando istanze multiple che vengono ovviamente con un sovraccarico operativo?

=> Concentrarsi prima sul prodotto/funzionalità. Quindi mira al livello 1, concentrati su altri livelli più tardi.

Con Docker (almeno dal mio punto di vista come un ragazzo, che non ha fatto molto con esso): L'artefatto del tuo sviluppo è un'immagine di un contenitore eseguibile. Quando questo artefatto viene pubblicato su un repository, dovrebbe essere molto semplice aggiornare tutte le istanze per utilizzare questo nuovo artefatto. Quindi con un po 'di scripting e forse sth. come Kubernetes dovrebbe essere possibile spostare anche molte istanze in una nuova versione. Quindi penso che i nuovi sviluppi come Docker rendono ancora più fattibili le configurazioni multi-istanza.

Sto facendo anche un prodotto SaaS per la nostra azienda. Per noi è anche multi istanza a causa di problemi aziendali:

1. I nostri clienti sono molto interessati a tenere separati i dati dai concorrenti. Questo è molto più facile da mostrare con una strategia multi-istanza.
2. I clienti desiderano controllare a volte il ciclo di rilascio. Ad esempio, devono comunicare i cambiamenti di funzionalità ai dipendenti o è in corso un processo aziendale che non consente un aggiornamento. Quindi potrebbero voler aspettare con una nuova versione o addirittura saltarla. Di nuovo molto più facile con un'istanza per cliente.

Come sempre con questo tipo di domande, sto dando la mia opinione e la mia esperienza qui. Dipende molto dal tuo caso d'uso: SaaS ha un sacco di varietà.

Answer 2

Non hai bisogno di database diversi per ogni cliente se hanno comunque schemi condivisi. La maggior parte del software SaaS è multi-tenant e funziona in questo modo, un database comune con logica applicativa per assicurarsi che gli utenti possano accedere solo a cose a cui dovrebbe essere consentito l'accesso. Per esempio. Facebook non ha miliardi di database, uno per ogni utente, per assicurarci che non possiamo vedere le reciproche foto non pubbliche.

Inoltre, i problemi che stai cercando di risolvere non sembrano avere alcun impatto sulla portabilità della tua applicazione o la tua capacità di spostarli nel cloud. Se si è treat backing services, e.g. database(s), as attached resources allora non importa se ne hai uno o molti (anche se consiglio comunque di averne uno solo).

Si consiglia di leggere lo 12-factor principles per lo sviluppo e l'implementazione di SaaS. Sono un ottimo punto di partenza per pensare al software di architettura che funzionerà facilmente in un ambiente cloud-native. Mi concentrerei sulla risoluzione dei problemi aziendali del software e sulla sua architettura in un modo nativo del cloud, ad es. secondo i principi dei 12 fattori.

Nulla sui problemi che hai descritto suggeriscono che Docker vs. non-Docker è anche una preoccupazione rilevante in questo momento. Cioè tutti i tuoi approcci proposti potrebbero essere fatti in modo abbastanza simile con/senza Docker. Docker risolve i problemi dell'isolamento dei processi, impaccando le dipendenze a livello di sistema operativo, riducendo il sovraccarico delle risorse di elaborazione, la coerenza tra lo sviluppo e la produzione, ecc. E sembra solo indirettamente correlato a ciò che stai cercando.

Answer 3

Multi Tenancy è la strada da percorrere, è conveniente e più manutenibile. Immagina di avere 10 clienti su 10 diverse versioni della tua applicazione, il loro supporto diventa un grosso problema. Con la multi tenancy è possibile scalare automaticamente in base al carico e ridimensionare quando il carico è inferiore, con l'istanza multipla potrebbe essere necessario assicurarsi che almeno un'istanza sia disponibile per ogni cliente.

Pochi altri motivi per cui vorrei andare con multi tenancy

1. Una versione per creare e distribuire
2. Condividere le risorse, come il caching
3. test solo una versione della propria applicazione
test
4. sicurezza sarà semplificato
5. Utilizzare efficacemente CDN