Perché QuickBooks non può essere archiviato su Google Drive per più utenti

Prima di entrare nei dettagli, è importante comprendere che si tratta di un concetto generale e che possiamo in realtà ricondurlo a “perché le applicazioni client/server o basate su file di database condivisi non possono essere archiviate su storage sincronizzato (ad esempio Google Drive, DropBox, NextCloud, ecc.) quando l’accesso non è limitato a un singolo utente?” QuickBooks utilizza un meccanismo di file di database condiviso comune alle applicazioni in stile anni ’80, in cui un singolo file o insieme di file viene condiviso tramite un meccanismo di condivisione file e le singole copie dell’applicazione accedono ciascuna a questo file per modificarlo. Google Drive è un meccanismo di storage sincronizzato: significa che crea copie dei dati da una posizione all’altra. Le persone che lavorano sullo stesso file nello stesso momento possono sovrascrivere, e spesso lo fanno, le modifiche reciproche e l’aspettativa è che tali modifiche vengano riconciliate manualmente in seguito, ignorate, oppure che gli utenti vengano controllati per impedire loro di lavorare contemporaneamente.

Per alcuni tipi di applicazioni multiutente, lo storage sincronizzato può essere sfruttato, ma solo in situazioni in cui l’applicazione è in grado di essere bloccata dal sistema di storage per consentire modifiche solo quando non ne esistono altre. Ciò richiede un livello di integrazione non praticabile con la sincronizzazione generica dei file. La maggior parte dei sistemi che lo fanno utilizza un meccanismo di sincronizzazione integrato nel livello del database o dell’applicazione, non uno generico che deve funzionare alla cieca. Affinché l’integrità dei dati venga mantenuta con lo storage sincronizzato, è necessario che una sola persona modifichi un file alla volta, attenda che tutti i potenziali utenti ricevano gli aggiornamenti effettuati dopo il “salvataggio” di quel file, dopodiché un utente diverso può modificare quel file e ripetere il processo. Ma solo un utente alla volta può lavorare sul file e deve ricevere gli aggiornamenti dell’altro utente prima di aprire il file per modificarlo a sua volta. Altrimenti il sistema deve chiedere agli utenti quali modifiche conservare e quali scartare in ogni singolo caso.

Questo processo di integrità non può essere applicato a un file di database in alcun modo realistico. Il file è progettato per essere aperto e accessibile in continuazione, non solo per essere aperto, modificato e salvato rapidamente. Inoltre il salvataggio non è manuale e non è sempre prevedibile. In genere diamo per scontato che il salvataggio avvenga continuamente durante l’uso, ma il caching può rendere impossibile controllare manualmente anche tali operazioni di salvataggio. Questo, però, è necessario per ragioni di prestazioni.

La confusione nasce spesso perché un singolo utente, senza il timore che un altro utente acceda al sistema nello stesso momento, può utilizzare lo storage sincronizzato, come Google Drive o Apple iCloud, come meccanismo di backup (semplicemente crea automaticamente una copia remota) e/o come mezzo per replicare il file in modo che il singolo utente possa usarlo prima da una posizione e poi da un’altra senza dover spostare manualmente il file da un luogo all’altro. Finché quel singolo utente si prende abbastanza tempo nello spostarsi tra le posizioni per garantire che la cache sia stata svuotata e che le sincronizzazioni e i blocchi siano stati completati, oppure si assicura di non aver lasciato aperta la prima istanza dell’applicazione, può ragionevolmente presumere di avere un sistema sicuro (ma non può garantirlo completamente – il meccanismo comporta comunque un rischio minimo di race condition anche in tal caso). Poiché esiste “un modo” per utilizzare in sicurezza lo storage sincronizzato con l’applicazione in modalità a utente singolo, molti contabili o addetti alla finanza non tecnici presumeranno erroneamente che funzioni anche l’accesso simultaneo multiutente, che è una cosa del tutto diversa. Questo, tuttavia, non è possibile.

Ciò che accade è che si verifica una race condition tra più utenti e non si può mai essere del tutto certi che non si sia verificata. A volte i dati saranno semplicemente errati e non c’è dubbio che si sia verificata una race condition, poiché i numeri saranno assurdamente imprecisi. Ma più spesso, alcune transazioni andranno semplicemente perse anche dopo essere state verificate.

Facciamo un esempio. L’Utente 1 è a casa e inserisce una nuova ricevuta in QuickBooks. Questa modifica inizia a essere salvata sul computer locale e, una volta completata, comincia a inoltrare il nuovo file a Google Drive nel cloud (online). L’Utente 2 è in ufficio e in questo momento inizia a inserire il pagamento di un cliente su una fattura. La copia del file di dati di QuickBooks dell’Utente 2 è aperta e non può essere sovrascritta mentre è in uso, quindi la copia che viene inviata a Google Drive non può raggiungere l’Utente 2. Una volta che l’Utente 2 salva la propria modifica, anche la sua copia tenta di inviarsi a Google Drive. Google Drive deve ora fare qualcosa con due documenti che inizialmente erano identici ma che ora presentano due modifiche radicalmente diverse, e nessuna delle due copie le contiene entrambe. Non ha alcun modo possibile di unirle, quindi può o accettare l’Utente 1 come master e scartare le modifiche dell’Utente 2 (ad esempio, priorità al primo). Oppure può accettare le modifiche dell’Utente 2 e scartare quelle dell’Utente 1 (ad esempio, priorità all’ultimo). Oppure, naturalmente, può scartare tutte le modifiche e non accettarne nessuna. In nessun caso tutte le transazioni finanziarie degli utenti vengono conservate, anche dopo che le hanno salvate localmente. O l’Utente 1 o l’Utente 2 (o possibilmente entrambi) si ritroveranno improvvisamente con dati che credevano salvati e che invece sono svaniti. Aggiungete altri utenti e il problema non fa che ingigantirsi.

Parte del problema è che, lavorando a livello di accesso ai file e sincronizzando e condividendo i dati a livello di file completo, non c’è modo di bloccare un solo record o una sola riga, né di mantenere separate le transazioni o di unire le modifiche. Il file è un’unica entità ed è cambiato. È tutto o niente. Le singole applicazioni QuickBooks non possono comunicare direttamente tra loro, né attraverso il file di database, per coordinare scritture, salvataggi, letture, ecc. al fine di aggirare questo problema. Sono cieche e non possono sapere che altre applicazioni stanno cercando di lavorare con il file nello stesso momento, perché ciascuna ha la propria copia univoca del file: non c’è nulla di “condiviso” tra di esse che consenta la comunicazione. Le copie non sono collegate l’una all’altra, non c’è alcuno stato quantistico in gioco qui. E poi possiamo aggiungere i potenziali problemi legati all’uso di una o più istanze dell’applicazione in presenza di una connessione Internet lenta o difettosa o, peggio ancora, quando un’istanza è offline. Possono esserci ore o giorni di modifiche che devono sovrascrivere, o essere sovrascritte, quando la sincronizzazione avviene finalmente. Raramente parliamo di millisecondi, ma spesso di giorni di dati.

Il modo in cui questo problema viene gestito, quando viene gestito, dai file condivisi localmente è articolato su più fronti. Innanzitutto, esiste un solo file, non copie di quel file. Quindi tutte le modifiche sono disponibili per tutte le copie dell’applicazione contemporaneamente e istantaneamente. Quando un’istanza dell’applicazione sta per scrivere dati nel file, utilizza un meccanismo di blocco e segnalazione simile a come i Clustered File System consentono il funzionamento delle SAN, dove può segnalare alle altre istanze dell’applicazione che è in corso una modifica e che devono attendere il suo completamento, per poi aggiornare la propria copia dei dati prima di proseguire. Solo un’istanza può scrivere e tutte le altre devono attendere. Non ci sono race condition perché il blocco viene ottenuto prima di iniziare e rilasciato al termine. E tutte le istanze funzionano solo finché i dati sono attualmente accessibili; se la connessione viene persa, non sono in grado di procedere. Un meccanismo cruciale di protezione dell’integrità dei dati. Alcune applicazioni portano questo meccanismo a un livello ancora superiore e aggiungono canali di comunicazione diretti (anziché attraverso il file condiviso) per rendere questo processo più rapido e ottenere prestazioni migliori. Ma poche si spingono fino a questo punto, poiché, una volta raggiunto quel livello, è in genere molto più facile passare semplicemente a un’applicazione moderna piuttosto che tentare di forzare sistemi multiutente moderni su progetti vecchi di decenni.

Si spera che questo abbia chiarito il motivo per cui i contabili pensano comunemente che i file sincronizzati funzionino e perché spesso affermano che “ha funzionato per me” quando dovrebbero dire “sono stato fortunato” oppure “l’ho usato in uno scenario completamente diverso che non si applica a un ambiente multiutente”, e perché si può assolutamente usare Google Drive, NextCloud, iCloud, DropBox e altri con QuickBooks e altre applicazioni in stile legacy per backup e trasferimenti di dati, ma non si può prendere in considerazione di tentare di usarli come mezzo per ottenere l’accesso multiutente, poiché semplicemente non sono in grado di mantenere intatti i dati.