Supporta la multitenancy

Oltre al siloing di dati, potresti riscontrare problemi con

1. Disponibilità: con un solo titolare, possono eseguire solo DoS, ma anche quando i dati sono archiviati correttamente, un tenant può ancora esaurire le risorse.
2. Registrazione: tutti i messaggi di registro presumevano un singolo titolare. A meno che tu non registri il silo per inquilino, i tuoi messaggi di log potrebbero risultare meno utili.
3. Concorrenza: le app di singoli titolari possono essere eseguite con un carico moderato oppure una contesa elevata per alcuni blocchi può serializzare in modo efficace determinate operazioni. Se i blocchi vengono moltiplicati per l'utente, è possibile iniziare a vedere l'interleaving delle operazioni che non si sono verificate prima. È probabile che le condizioni di gara che difficilmente si sarebbero manifestate si manifestassero.
4. Nuove fonti di contesa delle risorse - dove prima potevi avere n socket e m filehandle, ora moltiplicare quello per-tenant.
5. Confidenzialità di compatibilità configurabile / retrocompatibile - laddove prima si può rendere obsoleto un componente mentre si sostituisce un componente sostitutivo, ora è possibile avere un tenant che richiede un componente e un tenant che richiede che il componente precedente venga sostituito indefinitamente.
6. Obiettivo di sottomissione - attualmente sei un destinatario di una citazione per problemi relativi alla tua azienda. Con più tenant, potresti dover rispondere alle richieste di citazione anche quando non sei parte dell'azione legale.

Alcuni di questi presuppongono che tu stia eseguendo tutti i titolari nello stesso spazio degli indirizzi (computer o cluster). Se ciascun tenant esegue il software sul proprio hardware, è possibile inserire alcuni dei precedenti e aggiungere:

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

Il problema più grande in multi-tenancy, secondo me, è la personalizzazione. Ciò accade di routine se si vende un'applicazione aziendale alle imprese. Potrebbe variare da qualcosa di semplice come ogni cliente che desidera le proprie pelli alla possibilità di configurare campi, regole, moduli e report aggiuntivi. Il livello di personalizzazione che devi supportare gioca un ruolo fondamentale nell'architettura.

La risposta di Mike è molto buona, e molti dei punti là quasi sottovalutano la loro complessità a causa della loro brevità, quindi prendi a cuore quelli.

Un punto che vorrei aggiungere è che dovresti disporre di buoni strumenti di gestione per creare (e in seguito gestire) nuovi tenant. A seconda dell'architettura fisica che si utilizza, questo può essere tutt'altro che banale, ed è qualcosa che viene spesso trascurato. I vantaggi di un software come prodotto di servizio entrano realmente in gioco solo quando c'è un gran numero di inquilini, quindi è necessario impegnarsi a fondo per provvedere a questo.

Estendere la risposta di Sriram; la personalizzazione per-tenant è praticamente vietata, tutto ciò che un tenant potrebbe voler cambiare dovrebbe essere configurabile . Per esempio. se la tua soluzione non soddisfa l'aggiunta dinamica dei campi di dati in almeno alcune aree chiave, verrai inondata di richieste di personalizzazione. È uno dei pochi casi in cui un piccolo anticipo aggiuntivo di complessità è in realtà ripagato (diciamo che va contro YAGNI, o almeno, questo livello di configurazione è quasi un requisito fondamentale, quindi ci avremo bisogno esso).