Devo mantenere basi di codici e database separati per un'applicazione software-as-a-service?

Suggerirei di attenersi a una singola base di codice nel miglior modo possibile a meno che non ci siano importanti personalizzazioni richieste dai client che non pensate possano essere riutilizzate per gli altri. Mantenere più basi di codice sincronizzate può trasformarsi in un incubo di manutenzione, che aumenterà solo quando la base del cliente aumenterà.

Come per il database, di solito è meglio mantenere il numero al minimo, ma ci sono alcuni casi in cui ha senso suddividere i dati del cliente in database separati:

1. Hai requisiti rigorosi (ad esempio l'assistenza sanitaria o finanziaria) sulla riservatezza dei dati dei clienti.
2. Le prestazioni del database diventano un problema.

Riepilogo: opzione 3

Un precedente datore di lavoro ha avviato il modello One app code base but separate database per company per supportare diversi client, e i client hanno finito per volere (e pagare) caratteristiche abbastanza diverse che hanno rapidamente finito con Seperate app code base and database per company . Quindi, sulla base delle esperienze passate, penso che seguirai la progressione simile. Non confondere le basi del codice cliente fino a quando non è necessario, dato che è un mal di testa, ma piuttosto pensare a come le tue pratiche sono e come gestirle, quindi quando sei costretto in quell'angolo, hai già un'idea di come fallo.

Ti consiglio di non tenere conto di One app code base and one database in quanto potresti scoprire che customerX vuole prendere i loro dati e andare da qualche altra parte (potrebbe anche trattarsi di un mandato di comparizione o di una perquisizione in cui devi consegnare i dati in un procedimento penale e potresti non essere in grado di tagliare i dati di altri clienti). Molte aziende preferiranno questa strada per la gestione del rischio perché in questo modo un bug nel codice non espone i dati di altre società (ad esempio se si dimentica un join o l'ID dell'azienda in una clausola where).

vorrei andare con l'opzione no. 1 perché

• backup & il ripristino per cliente è possibile fuori dalla scatola
• nessun rischio di esporre i dati del cliente A al cliente B a causa di un bug, ad es. manca FK nella query
• puoi facilmente ridimensionarlo o ridimensionarlo ( link ), nessun load balancer o DB replicati necessari
• è possibile avere client con diverse versioni installate, il che è utile quando si aggiornano gli aggiornamenti. potresti / dovrebbe aggiornare prima l'1% dei nostri clienti, se tutto va bene, aggiorna il prossimo 10% e poi aggiorna il resto.

Una base di codice di app, uno schema di database, ma probabilmente eseguire le app separatamente e avere il dbs utilizzare lo stesso schema in realtà essere diverse istanze di DB.

Non progettare per questo ora, ma potresti immaginare che se hai bisogno di comunicare tra questi ragazzi potresti esporre un'API e fare in modo che un altro servizio gestisca qualcosa del genere, quindi un'app monolitica è eh. È anche possibile migrare l'app in modo che venga eseguita sul server client se ne ha bisogno, e in generale si riduce la complessità del codice in generale. Fondamentalmente quello che sto dicendo è che non vedo davvero troppo dei vantaggi di un'applicazione monolite che è un'applicazione multi-azienda rispetto all'applicazione aziendale che è possibile eseguire più di. Ovviamente ciò dipende dalla natura del tuo problema, ma progetta in piccolo se puoi.

Gestisci caratteristiche diverse semplicemente attivando e disattivando diverse funzionalità tramite un tasto. Spero che questo non aggiunga troppa complessità. Se vedi fare molto codice se (permissionX) è sbagliato. Tanto più desideri funzionalità e funzionalità nel back-end e hai elementi di visualizzazione incorporati che puoi portare in una visualizzazione economica. Pensa a come fa wordpress, dovresti creare dei plugin e il sistema ha tutte le funzionalità, ma per avere il pulsante del sistema di pagamento devi pagarlo.

Personalmente, opterei per la terza opzione. Rails rende anche piuttosto semplice "sandbox" i dati relativi a un determinato utente in modo che altri non possano vederlo. Dal punto di vista delle prestazioni, avere un database per gestire tutti i dati può far sì che le query siano più lente ma esistono numerosi modi per migliorarlo.

Personalmente, andrei con l'opzione n. 1 allacciata con un sacco di autodisciplina fino a quando non avessi una comprensione molto buona del problema e quali parti dovessero essere estendibili per ogni singolo cliente. Dato che stai iniziando, probabilmente hai qualche idea su cosa vuoi personalizzare, ma i tuoi clienti vorranno personalizzare le cose in modi che non hai mai sognato. Se si dispone di una singola applicazione o di una base di codice singola o entrambe, si dovrà quindi preoccuparsi di come le esigenze speciali del cliente A abbiano un impatto sul client B e viceversa. Avere tutti nella propria sandbox è un buon modo per essere in grado di servire i clienti, soprattutto all'inizio, quando è davvero necessario mantenere i pochi clienti che hai. Una volta che il prodotto è maturo, avrai un'idea migliore su dove costruire i punti di estensibilità e su come creare una base di codice singola che possa servire la maggior parte dei clienti.

In termini di gestione, non è così difficile con un po 'di disciplina. Non ho un'orribile familiarità con il rubino, quindi non sono sicuro di quali strumenti esatti bisognerebbe utilizzare, ma con buone pratiche scm e alcuni strumenti di distribuzione automatizzati è possibile gestire la gestione mentre si sta iniziando. Se hai gli incubi che gestiscono questo codice base e tutte le app separate, probabilmente hai un buon problema da avere. Molto meglio di capire come personalizzare un singolo codebase monolitico nella maggior parte dei casi.

Consiglierei la terza opzione per alcuni motivi.

Una base di codice faciliterà la manutenzione. Potresti anche essere in grado di sfruttare le richieste dei clienti in funzionalità di cui altri clienti potrebbero beneficiare. Se si dispone di una base di codice frammentata, questo sarà molto più difficile da fare e mantenere. Non solo, ma se hai basi di codice separate, non appena sei di fretta, qualsiasi disciplina tu abbia di applicare le correzioni a ogni singolo codice di base è probabile che venga dimenticata o trascurata nella tua fretta.

Per quanto riguarda il database, mentre avere più database per client suona abbastanza bene a questo punto del progetto, poiché il prodotto cresce e matura, è possibile che una società sorpassi le altre in termini di utilizzo. Ciò farà sì che sia necessario scalare separatamente ciascun singolo database. Se si utilizza un database per tutti i clienti, è necessario ridimensionarlo solo al crescere dell'utilizzo generale. È possibile che si verifichi un problema se un client è MOLTO più grande degli altri, ma può essere risolto analizzando il database al momento opportuno. Questo potrebbe darti il vantaggio di avere un database per client, senza il fastidio di mantenere effettivamente database separati.

Un altro problema con avere un singolo database per cliente è - cosa succede quando è necessario modificare la struttura del database per qualche motivo? Avrebbe bisogno di migrare ogni singolo database? Sebbene Ruby abbia strumenti che ti aiutano ad aggiornare i database, continuo a considerare più migrazioni come un rischio non necessario.

Se non hai la necessità di avere tutto separato, mantieni tutto il più simile possibile. Per motivi di sicurezza, è sufficiente assicurarsi che tutte le chiamate al database includano un riferimento al client che richiede i dati. Fintanto che questa regola viene applicata (e vengono adottate misure di sicurezza adeguate) non dovrai preoccuparti delle società che vedono i dati degli altri.