Supportare la multi-tenancy

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.

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.

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.

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).