La multi-tenancy è un problema difficile. Molto difficile. Ho visto un sacco di aziende farlo, pochissime di loro l'hanno fatto bene .
Per citare solo uno dei tanti esempi di dove i sistemi multi-tenant possono cadere a pezzi, si consideri cosa accadrà quando un cliente desidera un data warehouse o un database di reportistica ad-hoc. Riuscirai a farne una relativamente semplice, o dovrai passare attraverso un processo di scrub di dati immensamente doloroso che richiede sempre una lunga esecuzione, deve eliminare una serie di chiavi e vincoli e spesso perde dati che tecnicamente dovrebbero essere condivisi?
Ho visto quest'ultimo scenario accadere almeno due volte. Non è raro.
I sistemi multi-tenant devono essere scritti come sistemi multi-tenant da zero. Se provi a convertire una tradizionale farm multi-istanza in un sistema multi-tenant, lo lo rovinerà per diverse iterazioni. E se scegli di riscrivere ... beh, buona fortuna .
C'è sono molti vantaggi per i sistemi multi-tenant, ma contrariamente a (apparentemente) credenza popolare e / o intuizione, la produttività è non uno di loro, a almeno non fino al momento in cui si stanno mantenendo dozzine o anche centinaia di istanze separate. Aggiunge un'enorme quantità di complessità, correlata sia all'aspetto grafico che alla logica aziendale stessa. Probabilmente avrai bisogno di un qualche tipo di regole o motore del flusso di lavoro. E le tue prestazioni di uptime e supporto / call center diventeranno improvvisamente molto più sensibili, perché qualsiasi errore riscontrato influirà su tutti i tuoi clienti, non solo su uno.
Inoltre sicuramente devi regnare nelle personalizzazioni se ogni cliente si trova su un sistema condiviso. Alla fine ti imbatterai in una situazione in cui due clienti diversi hanno requisiti mutuamente esclusivi e dovranno scegliere una vittima. Se la tua organizzazione, come tante organizzazioni, ha difficoltà a dire "no" ai clienti paganti, questo ti morderà, difficile.
La maggior parte dei risparmi sui costi che la multi-tenancy ha storicamente fornito sull'hardware può essere ottenuta anche oggi con la virtualizzazione. Con vSphere o prodotti simili è quasi banalmente facile e veloce generare nuove istanze, anche se l'installazione è normalmente molto complicata.
Ciò che non si ottiene con la virtualizzazione è la distribuzione semplificata (nuove versioni) e la capacità di eseguire il data mining. La domanda è, sarebbe uno di questi vantaggi in questo momento?
Distribuire 1 aggiornamento invece di 10 aggiornamenti potrebbe essere più facile ... se hai un QA molto stretto e sei estremamente sicuro della stabilità del prodotto. In caso contrario, quel 1 enorme aggiornamento è molto più rischioso dei 10 piccoli aggiornamenti. Solo tu (e la tua azienda) puoi decidere quale ti si applica. E per quanto riguarda l'analisi - se non sei abbastanza esperto in analisi o se leggi / regolamenti sulla privacy ti impediscono di fare questo tipo di data mining, allora non dare per scontato che un database condiviso inizi ad avvantaggiarti in un lontano futuro .
Per essere chiari, non sono contro multi-tenancy, ma non sei la prima persona a porre la domanda o la prima azienda a seguire questa strada. Non dare per scontato che sarà facile consolidare, e sicuramente non presumiamo che sarà più facile da mantenere in seguito. In genere è molto più difficile; dovresti andare con quella soluzione solo se i suoi benefici specifici sono particolarmente importanti per te.
Per i venditori senza un enorme numero di clienti, è probabilmente meglio investire il proprio tempo nell'automazione di test e release. Se hai una suite completa di test di regressione in esecuzione ogni notte e puoi fare una promozione in 10-15 minuti (generalmente parallelizzabili), il numero di istanze tende a non importare che molto. C'è un limite, sì, ma ... saprai sapere quando ti ci avvicini.