Most applications are built to rely on the cloud. However, many organizations are starting to realize that dependence on the cloud has disadvantages. The challenges of overreliance on the cloud are most evident in industries like aviation, quick-service restaurants, e-commerce and healthcare, where deskless workers rely on mobile apps to get their jobs done.
The use of the cloud in practice
Think about how a modern fast food restaurant uses mobile technology today. Customers enter their menu choices at kiosks in the restaurant, on handhelds at the drive-thru or at points of sale. Their order is then sent to screens in the kitchen so that the order can be prepared. When it is ready, an alert is sent to the counter staff to hand it over. While it sounds simple, in reality this is a complex, mission-critical workflow where it is critical that data is synced and shared in real time.
This data must travel to a remote data center on the other side of the world to reach a device in the same building. Business apps become unusable if the data connection is slow, a Wi-Fi router breaks down, or there is an outage in the cloud service.
Because cloud-only applications have so many single points of failure, operations are halted while waiting for a device to reconnect. Such apps don’t provide a great user experience and end up costing companies money, customer experience, or worse. In situations such as healthcare, where decisions about a patient’s treatment are recorded and updated on mobile devices used by a team, these interruptions and their impact on rapid decision-making can have serious consequences.
Finding ways to connect those different devices directly together is an obvious solution. Peer-to-peer networking between devices is indeed common; How many times have you used AirDrop to send photos to a friend’s smartphone?
So why aren’t there more collaboration apps built with optional cloud features so they can function without the internet?
One answer is that it has been easier to build cloud-only applications. Thanks to the plethora of cloud-only databases and tools, developers don’t have to worry about TCP/IP networking, database partitioning, or on-disk compression when they need to update a field in a database table.
Going beyond cloud-only applications
Offline-first applications, on the other hand, were challenging to implement due to the limited tools available to support them. There are scalable peer-to-peer protocols for data that doesn’t change, like AirDropping photos. However, developers need the reliability of a database when data updates need to occur in real time or with super-accuracy. To do this, an offline-first datastore must be built that can handle offline and peer-to-peer changes.
But where to start? A data store model that allows these in-the-field apps to operate without a cloud connection has several key characteristics.
First, it must be easy to use for software developers. Instead of sending data to a remote server, the application must first write data in the form of changes to the local database, then detect changes from other devices and recombine them if necessary. Devices must be able to discover, connect and maintain these connections with nearby devices in a so-called mesh network. It is important to note that creating mesh networks for peer-to-peer data synchronization is not a silver bullet for enabling an organization to move to the cloud when necessary. These networks generate massive amounts of data that can overwhelm small devices as each node aggressively tries to sync every piece of data, becoming a drag for businesses and halting operations.
To overcome this, different types of devices should have different responsibilities when it comes to syncing the data. Smaller devices such as phones and tablets that have less processing power and storage capacity can focus on syncing the data explicitly requested by other devices, rather than entire documents, so as not to overload the device’s bandwidth. This means that these smaller devices can sync data incredibly quickly because only the deltas are exchanged. Larger devices, such as local or cloud servers, connected to the mesh via the Internet should be responsible for syncing as much data as possible, ensuring data access and visibility for users not directly connected to the local mesh .
When looking at the latency aspect of synchronization, a peer-to-peer mesh network should make it easy for other devices to join and leave when needed. Within this model, it is critical to ensure that all devices have input from the same data source. However, this poses a major mathematical challenge as the mesh network topology changes over time. So it’s important that these mesh networks are flexible, without needing the entire history of a database table to write or read the latest value. Therefore, create an ad hoc network.
For this to be successful, the peer-to-peer mesh network must understand that devices are updated regularly, but at different times. So it has to take into account the incoming data with different schemas. This way, even if a device is offline and therefore outdated, it should still be able to read and sync new data. The way to do this lies in the way the network works with a device in a reliable order of changes that can be inspected, which also includes recording metadata about schedule changes over time.
Developers need the right tools to build cloud-optional apps with purpose. When there is an outage, all devices should see the same query results given the same set of changes, even if the changes arrive in a different order. It’s a challenge for development teams to create a reliable, offline-first, peer-to-peer data store that syncs data across a partially connected mesh. However, as cloud-optional options become more attractive, there will be a growing demand for a complete end-to-end solution that combines the best of cloud software with the best of peer-to-peer software.
We recommended the best cloud computing.
This article was produced as part of Ny BreakingPro’s Expert Insights channel, where we profile the best and brightest minds in today’s technology industry. The views expressed here are those of the author and are not necessarily those of Ny BreakingPro or Future plc. If you are interested in contributing, you can read more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro