Cloud POS: App vs. Browser

Cloud POS has two distinct sides: the Cloud that provide services and the Store consuming those services for Front and Back-office operations. The overall scalability, SLA, openness and efficiency depend obviously on the design of both sides.

On the Cloud side I gave some opinions in “Cloud POS: native vs. hosted”. Now I switch to the Store side analyzing the App and Browser alternative approaches.

A Cloud POS App is based on native code optimized for the Operating System of the target device, designed to consume web services and deployed automatically from a web site or marketplace. The term has been made popular by mobile devices, but apply also to PCs.

A Browser based Cloud POS can run Java Script code and manage a local cache in different operating OS. The Browser is a software layer that trades efficiency for interoperability. App and Browser based POS are both 100% Cloud, according to the 2nd of the 5 essential characteristics of Cloud Computing defined by NIST. The term “Hybrid POS” apply only to traditional software that exchange files in batch mode with Cloud services, even when done at high frequency.

In the current marketplace, the main difference between the two technical approaches is that Browser based POS use the Central database not only for stock management and reporting, but also for synchronous request on Products, Promotions and Customers during sale. Some Browser based POS rely on HTML5 local cache as a backup for off-line operations, while the others just stop working.

App based POS, on the other hand, search on the embedded database for sale operations in on-line AND off-line mode and rely exclusively on asynchronous messages queues for bidirectional communication with Cloud resources. The reason is simple. Why design and manage a limited local cache just for rare off-line events? Why not expand and keep always updated (it should be done also for backup purposes anyway) in order to leverage it for faster operations, lower load on connectivity and Cloud resources and seamless POS operations?

Some additional considerations can also be made:

• Synchronous requests are simple but doesn’t scale well in the Cloud side. HW resources must be dimensioned for the peak load and remain unused in the short valleys. In contrast, asynchronous data exchange let some peak remain shortly in the message queue to be processed in the next valley, improving the resources utilization factor. Message queues are also the technique to exploit rapid elasticity (another essential characteristics of Cloud Computing) for handling efficiently longer workload variation. A queue persistently full is the trigger for additional resources, on the contrary when a queue is persistently empty, resources are released.
• The more local resources are leveraged by the App, the less are consumed in the Cloud. Fewer hits on the central database reduce the load on the less easily scalable part of the Cloud.
• Data can’t travel faster than the light and routing takes additional time, so Internet latency is unavoidable. Therefore a Cloud POS App is inherently more responsive thanks to local data and higher code efficiency.
• Bandwidth in some store may be limited and in any case shouldn’t be wasted. The App embedded database reduce the round trips to the Cloud and it can also avoid sending data already available locally, such as Product and Customer descriptions, reducing data transfers size for reporting.
• Intelligent Apps not needing connectivity and Cloud resources for normal operations, nor even requiring switching from on-line to off-line mode, assure a higher SLA.
• Apps use local I/O channels more directly and efficiently: a crucial advantage with legacy POS peripherals.

In short, a native App is inherently faster, more fluid and efficient than a browser based application.

That’s the reason for choosing the App way for aKite, even if we had to completely redesign on new paradigms and additional efforts are required for portability on multiple operating systems.