Un'istanza enorme di un'app o molte di medie dimensioni?

Question

Un'applicazione web che abbiamo scritto destinata a un cliente verrà prodotta e venduta a dozzine di aziende, e faremo l'hosting.

Potrei usare alcune indicazioni sui vantaggi e gli svantaggi di implementare un'istanza separata per ciascun cliente anziché andare con un singolo (o un numero molto piccolo) di istanze multi-tenant.

All'inizio, mentre avanziamo, dovrò lanciare un'istanza separata dell'applicazione per ogni nuovo cliente (arriveranno online uno alla volta) perché è l'unica opzione immediata . Immagino che questo non si ridimensionerà molto bene per quanto riguarda la manutenzione: l'implementazione delle modifiche diventerà molto noiosa e probabilmente soggetta a errori una volta che ci saranno più di 4 o 5 istanze là fuori. A meno che non lo automatizziamo in qualche modo.

Inoltre, la filosofia della singola istanza sembra che potrebbe portare a un sacco di forchette se le persone hanno bisogno di personalizzazioni. E sarebbe bello evitarlo.

Qual è stata la tua esperienza con questo?

Domanda bonus n. 1: Qual è la differenza di prestazioni tra 10 server SQL con record da 2 m ciascuno rispetto a uno enorme con 20 m? Diciamo che sono tutti in una tabella e stiamo principalmente facendo inserimenti e selezioni su singoli record. A volte le selezioni si trovano su un varchar indicizzato (12) o su un campo data.

Bonus domanda n. 2: Immagino che per evitare il fork, dovremmo rendere configurabili le personalizzazioni o costruire un'architettura plug-in. Tuttavia, ciò potrebbe aumentare il costo delle personalizzazioni e non voglio essere uno di quei negozi che impiegano una settimana per ridimensionare una casella di testo, e in cui non voglio investire eccessivamente infrastruttura. Qualche idea su questo?

Dettagli scala

Ogni cliente avrà una discreta quantità di dati - fino a qualche milione di record.

Ci sarà un numero molto piccolo di utenti simultanei, solo pochi per cliente, oltre a una manciata di rappresentanti interni da parte nostra.

Non è chiaro se ogni cliente richiederà personalizzazioni, ma direi che alcuni probabilmente lo faranno, e forse alcuni di quei cambiamenti saranno cose che altri clienti non vorranno vedere.

Answer 1

Non vedo un buon motivo per nessuna delle due opzioni. Penso che la vera risposta sia da qualche parte nel mezzo: avere più istanze, ognuna delle quali ospita più client.

Questo aggiunge un altro livello di elaborazione dell'automazione, ma significa che puoi mantenere l'hosting a buon mercato (non avrai bisogno di uscire e comprare un Cray in qualsiasi momento presto) e (si spera) questo tipo di mentalità significa che potresti fare un failover backup abbastanza facilmente.

Ma non anticipiamo noi stessi ... Stiamo parlando di una webapp, giusto? Ottieni il tuo database (s) e aspnet su macchine diverse. Cluster i tuoi database e ti divertirai molto più a giocare con vari scenari front-end. Sarai anche in grado di effettuare l'upscaling di qualsiasi area per prima esaurisca il soffio.

A quanto pare, finirai con un database cluster oltre la metà se non una dozzina di macchine database e solo un paio di caselle front-end.

Per quanto riguarda le personalizzazioni, l'hai inchiodato. O fornisci un set di modelli modificabili completamente ospitato nel database o devi personalizzare quali istanze. Sono tutto per il primo. È un sacco di lavoro (senza molto in cambio) ma ne vale la pena in quanto dovresti solo cambiare il codice principale quando (lo farai!) Esegui gli aggiornamenti. Cercare un centinaio di istanze personalizzate dei clienti per assicurarsi che eseguano l'aggiornamento in modo sicuro ucciderà uno sviluppatore! I modelli sono la risposta. Per lo meno, potresti consentire CSS personalizzati senza molto dolore (ma avrebbero bisogno di qualcuno che conoscesse le loro cose).

Modifica: ho visto un paio di post dedicati al metodo all-in-one. Dividere le istanze su più macchine ti isola da un paio di cose:

• Se si introduce un bug non rilevato durante il test, vengono eseguiti solo pochi client alla volta

• Hardware non riuscito. La caduta di un mega-server infastidirà molte persone contemporaneamente. Avere un mega-server di failover è enormemente costoso. Avere una scatola di failover di riserva per tre o quattro server in esecuzione è molto più economico e infastidisce meno persone.

• Le prestazioni possono essere bilanciate tra le caselle in base al cliente, in modo da poter mettere alcuni client di uso leggero con un client pesante o semplicemente riempire una casella con alcuni client di medio utilizzo, ecc. .

• Sulla stessa idea, picchi di utilizzo o altri rallentamenti hanno effetto solo sui client nella stessa casella. Naturalmente questo non significa lo stesso per il database, ma puoi dividerlo in un cluster di cluster quando ci arrivi.

Answer 2

di fronte a una sfida simile, ecco cosa abbiamo fatto:

1. abbiamo una base di codice con più server sql. manteniamo più server iis con copie della stessa base di codice. siamo liberi di spostare i client dal server sql al server sql per massimizzare le prestazioni.

2. se un cliente ha $ per esso, li installeremo sul proprio server e manterremo un server iis separato per loro. questo accoglie i clienti più grandi per i quali paga ogni mese molti più soldi (10 volte più soldi). tuttavia, non forniamo loro una base di codice separata. se hanno bisogno di una mod, la rendiamo visibile in base al cliente (vedi # 3)

3. la programmazione personalizzata di solito si traduce in un'opzione configurabile. anche le persone che ci pagano per avere il proprio server ottengono la stessa versione del codice. a volte è semplice come una clausola nel codice che dice "se il cliente =" nostro cliente, attiva questa opzione ". sì, è un codice difficile, ma se il cliente ha abbastanza soldi, va bene per me.

4. Non ho capito bene se volevi mescolare i dati di diversi clienti in un unico grande database .. la nostra regola è che mai farlo (mai e poi mai). è una delle scelte più sagge che abbiamo mai fatto. rende la manipolazione dei dati molto meno rischiosa e ripristina i dati più facilmente.

Answer 3

Il grande vantaggio delle singole istanze si ridimensionerà all'aumentare della domanda di ogni cliente. Ad esempio, se si esegue su un singolo server e improvvisamente un cliente ha bisogno di più preformance, è pieno. Ma se sono tutti individuali, spostare quel cliente su un nuovo server brillante è relativamente semplice.

Il grande svantaggio sarà nella gestione delle istanze tutte individualmente. (indipendentemente dal fatto che siano tutti in esecuzione sullo stesso server o meno).

Indipendentemente da ciò, dovresti avere solo un'istanza della base di codice. E la personalizzazione dovrebbe essere controllata tramite plugin e configurazione. Il front-end dovrebbe naturalmente essere separato dal contenuto. Anche se il costo per apportare una modifica può essere più elevato, il vantaggio in termini di funzionalità che puoi offrire agli altri tuoi clienti (che saranno solo personalizzazioni che ti è stato chiesto di fare) sarà sicuro. Il che non vuol dire nulla di quanto sarà più facile gestire una singola base di codice, a differenza di molti.

Answer 4

Consiglio vivamente di seguire la singola istanza ospitata dalla tua azienda. Ciò presenta i seguenti vantaggi:

• Hai accesso fisico a tutto il codice e database per apportare modifiche e aggiornamenti.
• Controlli la qualità di hardware su cui è in esecuzione.
• Quando correggi un bug nel codice comune, l'hai risolto una volta per tutte clienti.
• È possibile riformattare l'applicazione progettare per supportare meglio il cliente codice specifico ed evitare il fork.
• Man mano che aumenta il numero di clienti può ridimensionare e ridimensionare il tuo server da incontrare prestazioni / risposta requisiti.
• Il codice dell'applicazione e i database non può essere manomesso da & Quot; inquistive " clienti.

Dovrei dire che è quasi più importante dove la tua applicazione è in esecuzione rispetto a quante istanze separate ce ne sono.

Certo, mantenere più istanze separate non è l'ideale a causa del sovraccarico di supporto / manutenzione, ma se queste app. sono tutti su server che controlli, la vita è molto più semplice quindi è necessario l'accesso remoto / fisico a reti e server di clienti diversi.

Joel Spolsky ne parla anche esattamente su Podcast StackOverflow 67 .

  

Una cosa che Joel ha imparato   vendita di Fogbugz: software progettato per   essere installato su un server internamente a   sito del cliente, sotto il pieno controllo di   quel cliente non vale quasi mai   la seccatura

20 milioni di record relativamente parlando non è un enorme database di SQL Server. Un unico SQL Server con provisioning in grado di gestire comodamente queste dimensioni. Più importante, tuttavia, è il numero di accessi simultanei al database. Tuttavia dici che ci saranno solo pochi utenti per cliente, quindi è improbabile che ti colpisca fino a quando il livello di concorrenza non aumenta.

Answer 5

Tutto quanto sopra è un buon punto ma mancano due domande chiave. A quale prezzo viene offerto il servizio e quanti clienti (ordine di grandezza) dovrai sostenere (ad esempio, le dimensioni del mercato)? Tra 3 anni avrai un massimo di 10 clienti, ognuno dei quali ti pagherà $ 500.000 all'anno o 500 clienti che ti pagheranno $ 10.000 all'anno? Per un piccolo gruppo di clienti premium paganti, i vantaggi delle singole implementazioni sono evidenti, mentre i prezzi più bassi e le basi di clienti più grandi richiedono una soluzione condivisa (il commento di la Oli) è il modo migliore di procedere. O andare con una piattaforma cloud, anche se ho letto solo l'hype e armeggiato piuttosto che distribuito sul campo.

Bonus Domanda 1: layout della tabella, indicizzazione, numero di letture / scritture, efficienza e complessità delle procedure memorizzate (stai usando procs o almeno dichiarazioni preparate, giusto?) contano molto di più del numero di record fisici nel database fino a un certo punto. Oltre a ciò, probabilmente ti ritroverai a dover fornire singole istanze di SQL Server per ciascun cliente o per un pool di clienti, ancora una volta a seconda di alcune delle domande che ho sollevato sopra.

Bonus Domanda 2: Dedicare il tempo al tuo design per il templating e un'architettura plug-in è essenziale in questa situazione e devi farlo prima piuttosto che dopo. Una volta che hai la voglia di personalizzare il codice per pagare i clienti, probabilmente non avrai il tempo di farlo nel modo giusto. Questo punto non può essere sottolineato abbastanza. I modelli e gli strumenti di amministrazione che ti offrono un accesso rapido e approfondito alle modifiche basate sui dati nel tuo prodotto ti faranno risparmiare molto tempo. Man mano che la tua azienda / gruppo si espande, puoi aggiungere meno personale tecnico che può essere "esperto di prodotti". chi può eseguire il 90% delle personalizzazioni e della manutenzione, liberando il core per continuare lo sviluppo o passare ad altri progetti. Infine, non trascurare il livello di dati in questo processo di pianificazione. Avere un livello di dati di base di proc e tabelle (quasi) immutabili memorizzati è molto importante, con tabelle personalizzate e proc memorizzati chiaramente delimitate usando una buona convenzione di denominazione.

Buona fortuna, non esitare a fornire maggiori dettagli se desideri suggerimenti più specifici.

Answer 6

Sulla base di alcuni dei consigli ricevuti qui, abbiamo finito per implementare una versione multi-tenant monolitica della nostra applicazione.

Sono contento di averlo fatto. Al tempo, avevamo 3 o 4 fork della base di codice (principalmente skin personalizzate e cose per le quali non avevamo il supporto di livello n, ma anche alcune funzionalità effettive), e stava diventando sempre più folle.

Abbiamo ottenuto la versione multi-tenant e ripiegato con successo tutto. Alla fine ci sono state molte cose su cui pensare e molte su cui tenere traccia, ma i nostri clienti non hanno nemmeno saputo di essere stati spostati in un nuovo sistema.

Dirò che l'attuale migrazione dei clienti è stata un po 'un orso. All'inizio ho pensato che saremmo stati in grado di farlo manualmente nel backend, ma alla fine ho dovuto scrivere alcuni script abbastanza coinvolti per portare a termine il lavoro. C'erano troppe colonne di identità e non è che puoi disattivare temporaneamente i vincoli durante l'importazione in un sistema di produzione live.