Supportare la multi-tenancy


10

Quali sono le sfide tipiche che si presentano quando si converte un'app single-tenant in un'app multi-tenant? La sicurezza e l'isolamento dei dati mi sembrano i più significativi. Quali sono alcuni altri?

Sono uno degli architetti per uno sforzo di automazione abbastanza significativo, e storicamente è stata solo la nostra azienda a usarlo. Vogliamo consentire anche ad altri di usarlo. Ogni volta che parliamo di "renderlo multi-tenant", la conversazione ruota attorno alla necessità di tenere gli utenti con un inquilino lontano dai dati di proprietà di un altro inquilino e di assicurarsi che gli utenti con un inquilino non possano (intenzionalmente o involontariamente) creare impatti in un altro ambienti degli inquilini. Quello che mi chiedo è se la sicurezza / l'isolamento dei dati sono davvero le uniche preoccupazioni principali qui, o se ci sono alcune altre preoccupazioni importanti alle quali non stiamo pensando.


La soluzione più semplice? Una nuova istanza dell'intero sistema, incluso l'hardware, vuoto, da zero, un nuovo sistema per inquilino. Se il sistema e i dati sono piuttosto preziosi, questa potrebbe essere un'opzione abbastanza buona. Se non ti piace il nuovo hardware per ogni istanza, usa la virtualizzazione. Potrebbe non essere il più efficiente, ma sicuramente salverà un sacco di mal di testa.
SF.

Probabilmente dal punto di vista del design questo è il più semplice, ma dal punto di vista amministrativo non sembra essere. Almeno i nostri amministratori di sistema non sono molto entusiasti di questa proposta. (E sì, stiamo usando macchine virtuali.) Molte più istanze da gestire (monitoraggio, distribuzione, ecc.) Stiamo infatti cercando modi per renderlo più gestibile per ottenere un po 'di isolamento fisico qui, ma a parte questo, questo approccio sembra scambiare dev semplicità per la semplicità dell'amministratore ...?

Risposte:


11

Oltre al silosing dei dati, potresti riscontrare problemi con

  1. Disponibilità: con un singolo inquilino, possono fare da soli DoS da soli, ma anche quando i dati sono correttamente messi a tacere, un inquilino può ancora esaurire le risorse.
  2. Registrazione: tutti i messaggi di registro hanno assunto un singolo tenant. A meno che non si registri di silos per tenant, i messaggi di registro potrebbero diventare meno utili.
  3. Concorrenza: le app a singolo tenant possono essere eseguite con un carico moderato oppure un'elevata contesa per alcuni blocchi può serializzare in modo efficace determinate operazioni. Se i blocchi vengono moltiplicati per tenant, è possibile che inizi a vedere l'interlacciamento di operazioni che non sono avvenute prima. È ora probabile che si manifestino condizioni di gara che molto probabilmente non si manifesteranno mai.
  4. Nuove fonti di contesa di risorse - dove prima potevi avere n socket e m filehandle, ora moltiplica quel per-tenant.
  5. Compromessi di configurabilità / retrocompatibilità: dove prima di poter obsoleto un componente mentre si avvia una sostituzione, ora è possibile che un tenant richieda un componente e un inquilino che richieda che il vecchio componente sostituito rimanga a tempo indeterminato.
  6. Target di citazione: al momento sei un target di citazione per problemi legati alla tua azienda. Con gli inquilini multipli, potrebbe essere necessario rispondere alle richieste di citazione anche quando non si è parte all'azione legale.

Alcuni di questi presuppongono che tutti i tenant siano in esecuzione nello stesso spazio degli indirizzi (macchina o cluster). Se ogni tenant esegue il software sul proprio hardware, è possibile eseguire il moot di alcuni dei precedenti e aggiungere:

  1. Difficoltà nell'accesso alle macchine per il debug.
  2. Richieste di supporto per versioni precedenti.
  3. Richieste di consentire la configurazione di appaltatori di terze parti.
  4. Meno controllo sull'hardware su cui gira.
  5. Meno controllo sul ciclo di patch / aggiornamento del sistema operativo su cui viene eseguito.

1

Il più grande problema nel multi-tenancy secondo me è la personalizzazione. Questo succede abitualmente se vendi un'applicazione aziendale alle imprese. Potrebbe variare da qualcosa di semplice come ogni cliente che desidera le proprie skin alla possibilità di configurare campi, regole, moduli e report aggiuntivi. Il livello di personalizzazione che è necessario supportare svolge un ruolo fondamentale nell'architettura.


1

La risposta di Mike è molto buona, e molti dei punti lì quasi sottostimano la loro complessità a causa di quanto siano corti, quindi prendi a cuore quelli.

Un punto che vorrei aggiungere è che dovresti avere buoni strumenti di gestione per creare (e in seguito, gestire) nuovi inquilini. A seconda dell'architettura fisica che segui, questo può essere tutt'altro che banale ed è qualcosa che viene spesso trascurato. I vantaggi di un software come prodotto di servizio entrano davvero in gioco solo quando ci sono molti inquilini, quindi una buona dose di sforzo dovrebbe essere dedicata alla ristorazione per questo.

Estendere la risposta di Sriram; per-tenant personalizzazione è praticamente proibito, tutto ciò che un inquilino potrebbe essere necessario modificare dovrebbe essere configurabile . Ad esempio, se la tua soluzione non soddisfa l'aggiunta dinamica di campi dati in almeno alcune aree chiave, verrai probabilmente inondato di richieste di personalizzazione. E 'uno dei pochi casi in cui un po' di ulteriore anticipo complessità realtà non pagare i (diciamo che va contro YAGNI, o per lo meno, questo livello di configurazione è quasi un requisito chiave, in modo da siete andando bisogno).


Perché la personalizzazione è "vietata"? È certamente tecnicamente realizzabile. Esistono molti modelli diversi che consentirebbero il riutilizzo del sistema principale per più inquilini, fornendo comunque pezzi personalizzati per i singoli inquilini. Se un cliente è disposto a pagarti per la personalizzazione sembrerebbe ragionevole considerarlo. Ci sono molti prodotti multi-tenant che hanno personalizzazioni per client per questo motivo. È più nello spirito di YAGNI IMO consentire l'estensibilità e non di default nel rendere tutto configurabile.
RationalGeek,

1
Bene, mi riferisco al software come implementazioni di servizi, in generale (da "multi-tenancy"). Certo, è tecnicamente realizzabile, ma va contro i fondamenti di SaaS. In senso finanziario, stai ottenendo costi più bassi condividendo l'implementazione e probabilmente l'infrastruttura per molti inquilini. Ciò ti consente di offrire il tuo prodotto a un prezzo inferiore, catturando così la "coda lunga" del mercato (un gran numero di persone disposte a pagare solo una piccola quantità). Puoi mantenere forse 5 rami di un sistema, ma non 15000, e questo è l'obiettivo di SaaS.
Daniel B,

A livello aziendale vedo spesso i fornitori SaaS che sono disposti a personalizzare in modo significativo il loro codice per far atterrare un cliente. Quando un cliente paga 6 o 7 cifre per il servizio, questo è probabilmente un modello di business ragionevole.
RationalGeek,

Sì, in quei casi, credo di si. La maggior parte delle modifiche che ho visto sono state implementate come nuove funzionalità configurabili che, per impostazione predefinita, sono state disattivate per i client esistenti. Il problema, penso, è quando i primi 3 o 4 clienti ricevono ciascuno un trattamento speciale perché la soluzione deve ancora decollare. La soluzione finisce per essere troppo specifica e crea una cultura di "OK, ci limiteremo a modificarla". Sì, sono d'accordo con il tuo commento su grandi clienti.
Daniel B,

Questa è una distinzione utile che voi ragazzi state facendo intorno alla personalizzazione. Penso che lo stesso concetto potrebbe valere anche per la gestibilità. La nostra multi-tenancy mira probabilmente a un numero relativamente inferiore di clienti più grandi piuttosto che a clienti long-tail. Se lo scopo principale della multi-tenancy è catturare la coda lunga, potrebbe non essere nemmeno l'approccio giusto per noi. Grazie per queste riflessioni.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.