App multitenant o istanza separata per ogni cliente

Ci sono alcuni compromessi che dovrai fare:

1. Istanze dedicate

Vantaggi:

• Nessun ulteriore sviluppo necessario né lavoro concettuale (meno tempo e costi per commercializzare il prodotto)
• Ogni cliente è completamente indipendente, il che significa flessibilità tecnica (è possibile scegliere una struttura di hosting in base alla posizione, al prezzo del volume, ecc.), possibilità di personalizzazione (un cliente può richiedere una versione speciale su misura) e maggiore sicurezza (no rischio che un cliente possa accedere ai dati di altri clienti o che i danni su un cliente, come l'attacco di SQL injection, possano avere un impatto sugli altri.
• È possibile offrire lo stesso prodotto per il cliente per l'installazione nelle proprie premesse se desidera

Inconvence:

• Nessuna economia di scala: devi gestire tutti questi server, il che significa un sovraccarico tecnico per ogni nuovo cliente (non solo installazione, ma anche monitoraggio, patch di sicurezza, previsione di ulteriore spazio su disco necessario, ecc.).
• Manutenzione costosa: il processo di aggiornamento in caso di una nuova versione del prodotto dovrebbe essere ripetuto per ciascun cliente.

2. Architettura multi-tenant

Vantaggi:

• singolo software per la mainain
• economie di scala per le operazioni
• quindi, in ultima analisi, economicità e prezzi più convenienti per il cliente (o margini più elevati per te).

Inconvenienti:

• sei vincolo nella personalizzazione per i clienti.
• un investimento iniziale più elevato nello sviluppo: la multitenancy deve essere progettata (non così facile come sembra), una funzionalità progettata deve prendere in considerazione varianti portali per diversi clienti
• maggiori rischi operativi (ad esempio, la scalabilità e la gestione delle prestazioni devono essere garantite considerando i volumi più grandi + possibili colli di bottiglia nascosti + rischio per la sicurezza dei clienti incrociati + i problemi potrebbero interessare tutti i clienti nello stesso tempo)

3. Altra alternativa: microservices?

Un terzo scenario potrebbe essere quello di tagliare la tua applicazione in microservizi . La scalabilità sarebbe massimizzata. Spetterà comunque a te decidere se dividere i servizi per cliente o se sceglierai multi tenancy, ma l'intera architettura è progettata per rendere queste scelte relativamente facili. L'applicazione avrebbe bisogno di una reingegnerizzazione completa.

Raccomandazione

Penso che l'opzione 1 sia il modo di scegliere se hai qualche grande cliente o, come soluzione temporanea, nel caso tu debba andare sul mercato molto rapidamente.

L'opzione 2 mi sembra la scelta più razionale se hai molti clienti e se vuoi ottenere economie di scala.

L'opzione 3 sarebbe la scelta giusta se scegli l'opzione 2 ma se prevedi problemi di scalabilità. Vai direttamente a questo approccio se ti aspetti un numero enorme di clienti

Se costruisci l'app per supportare più tenancy, i tuoi futuri rappresentanti tecnologici avranno una scelta su come implementarlo. Se trovi un cliente che insiste su un'istanza single-tenant, sarai in grado di supportarli. Alcuni clienti preferiscono questo approccio per motivi di infosec.

Allo stesso tempo, sarai in grado di eseguire operazioni multi-tenant. Ciò ti aiuterà a scalare l'applicazione raccogliendo clienti. Ci sono diverse parti in questo.

1. ridimensionamento tecnologico. Più clienti su una singola istanza ti terranno onesto sui colli di bottiglia e le condizioni di gara, dove potresti non affrontare questi problemi in molte piccole istanze. Avrai anche un tempo più facile con sysadmin e il lavoro di backup.
2. Ridimensionamento aziendale. Un sistema multi-tenant può gestire economicamente prove e piccoli clienti.
3. Scalabilità sul successo dei clienti. Cosa succede se a un cliente piace il tuo prodotto così tanto da richiedere a tutti i suoi fornitori di utilizzarlo? Con il multi-tenant, questo è un upload della lista dei clienti. Con single-tenant, questo è un sacco di rigging di esempio.

Il multi-tenant è la soluzione ideale per la progettazione di app. Mantiene le scelte aperte.

La scelta non è chiara e potresti facilmente adottare un approccio ibrido. Ad esempio, Atlassian consente di utilizzare i loro strumenti (Jira, Bitbucket, ecc.) Sul proprio server, ma consente anche di installare sul proprio server.

Il lato negativo di un'istanza per cliente è che ogni aggiornamento deve essere inviato a tutti i clienti, ma potrebbe avere la possibilità di farlo o meno. Nota che non tutti i clienti sono felici di avere applicazioni in continua evoluzione! Potresti non avere tutto sotto controllo, però. Pensa a backup, sistemi operativi per server, ecc. Decine di possibili punti di conflitto.

Per applicazioni in rapida evoluzione, penso che un'app centrale abbia senso. Ti darà solo un altro tipo di mal di testa. E se ti incasini qualcosa, tutti i tuoi clienti sono interessati allo stesso tempo.

Note a margine: Potrebbe avere senso nell'approccio central-app per mantenere i dati degli utenti in database separati. Inoltre, è possibile utilizzare installazioni separate per ciascun cliente, ma in un ambiente controllato nel data center, in modo da avere il controllo completo. Ricorda sempre che la complessità cresce esponenzialmente con il numero di opzioni.

Ho visto 2 sviluppi accadono in ogni applicazione su cui ho lavorato che era multi-cliente ma single inquilino:

• Una funzionalità è richiesta solo per uno specifico cliente che vuole pagare per questo. Anche per l'avvio di maggior successo questa caratteristica è difficile da resistere, quindi le basi di codice per le app divergono a causa delle pressioni temporali. A un certo punto, diventano insormontabili, cosa che, se il software multi-tenantato riesce, lascia la singola locazione nella polvere. Il caso peggiore è che ora sono necessari molti interventi di manutenzione per gestire più software.
• Anche nelle economie più piccole (la mia è la Nuova Zelanda), troverete rapidamente clienti che necessitano di una sorta di superutente aziendale in grado di accedere a tutti i record dei reparti, mentre è necessario tenere separate più tenancy dei loro subordinati. Questo è esattamente lo stesso della multi-tenancy application wide, quindi alla fine dovresti costruirlo in ogni caso.