Cloud POS: App vs. Browser

Un Cloud POS ha due lati distinti: il Cloud che eroga servizi software e il Negozio che li utilizza per le operazioni di Front e Back Store (cassa e gestione). La capacità di gestire anche grandi catene (scalabilità) e il livello di servizio (detto anche SLA da Service Level Agreement) dell’intero sistema dipendono ovviamente dalla progettazione di entrambi i lati.

Sul lato Cloud ho già dato qualche opinione in “Cloud POS: nativo vs. hosted”. Ora passo al lato del negozio per analizzare gli approcci alternativi basati su App e su browser.

Un’App POS è basata su codice nativo ottimizzato per il Sistema Operativo dell’apparecchiatura utilizzata come punto cassa, progettata espressamente per “consumare” i servizi Cloud. L’installazione avviene da una pagina web o da un marketplace. Il termine App è stato reso popolare dai dispositivi mobili, ma si applica anche ai PC.

Un Browser POS può ospitare codice Java Script e gestire una cache locale su differenti Sistemi Operativi. E’ uno strato software aggiuntivo che fornisce interoperabilità in cambio di efficienza.

I POS basati su App e su browser sono entrambi Cloud al 100% in base alla seconda delle cinque caratteristiche essenziali del Cloud Computing definite dal NIST. Il termine “POS ibrido” (hybrid) si applica solamente a dei software tradizionali che scambiano file con il Cloud in modalità batch, anche se questa operazione avviene con elevata frequenza.

Nel mercato attuale, la principale differenza tra i due approcci è che i POS basati su browser usano il database centrale non solo per il magazzino e le statistiche, ma anche per richieste sincrone su Prodotti, Promozioni e Clienti durante le normali operazioni di vendita. Alcuni di questi utilizzano la cache locale gestita da HTML5 come riserva per l’operatività in assenza di connessione (off-line), mentre altri si bloccano.

Invece i Cloud POS basati su App cercano i dati di vendita sempre su un database locale, sia in on-line che in off-line, ed utilizzano esclusivamente messaggi asincroni per scambiare richieste e informazioni con i servizi Cloud. La ragione è semplice. Perché progettare e gestire una cache solo per il raro evento della mancanza di comunicazione e con severe limitazioni? Perché non espanderla e tenerla costantemente aggiornata (cosa che si dovrebbe fare comunque anche per soli scopi di backup) sfruttandola per velocizzare le operazioni, ridurre il carico su linee e risorse Cloud e dare alla cassa un’operatività ininterrotta?

Si possono fare numerose altre considerazioni:

• • Le richieste sincrone sono tecnicamente semplici ma non scalano bene sul Cloud. Le risorse HW devono essere dimensionate per i picchi e rimangono inutilizzate nelle valli. Negli scambi di richieste asincrone, invece, parte dei picchi rimangono in coda per essere elaborati nella valle successiva, aumentando il livello di utilizzazione delle risorse. Le code di messaggi sono anche lo strumento per gestire l’elasticità rapida (un’altra caratteristica essenziale del vero Cloud Computing) per gestire efficacemente fluttuazioni del carico di lavoro più lunghe. Una coda piena in modo persistente fa scattare l’acquisizione di nuove risorse, mentre una vuota ne provoca il rilascio.

• • Come è facile intuire, più risorse locali vengono sfruttate dalla App, meno ne vengono richieste al Cloud. Minori richieste al database centrale riducono il carico di lavoro sulla risorsa meno facilmente scalabile del Cloud.

• • I dati viaggiano alla elevata ma finita velocità della luce e il passaggio da una rete all’altra (routing) richiede tempo aggiuntivo, per cui su Internet una certa latenza (ritardo) è inevitabile. Pertanto un Cloud POS basato su App è intrinsecamente più responsivo grazie ai dati locali e alla maggiore efficienza del codice nativo.

• • La capacità della connessione (detta anche banda) in certi punti di vendita può essere limitata e in ogni caso non deve essere sprecata. Il database embedded delle App POS riduce le richieste al Cloud ed evita di mandare dati già disponibili localmente, come ad esempio descrizioni di Prodotti e Clienti, riducendo le dimensioni dei trasferimenti per i report.

• • Delle App intelligenti che non richiedono connettività al Cloud per le normali operazioni di vendita e non richiedono nemmeno un passaggio di modalità da on-line a off-line, assicurano uno SLA superiore.

• • Le App usano i canali locali di Ingresso/Uscita (I/O) in modo più diretto ed efficace: un vantaggio cruciale per gestire le periferiche POS. In sostanza una App nativa è intrinsecamente più veloce, fluida ed efficiente di un’applicazione basata su browser.

Questa è la ragione che ci ha indotto a scegliere la via delle App per aKite, anche se è stato necessario riprogettare su paradigmi completamente nuovi e sforzi ulteriori sono richiesti per la portabilità su diversi sistemi operativi.