How To Support Offline With The Cloud
The cloud has become the new normal with so many companies leveraging the vast capabilities and flexibility that cloud providers are creating. However, one thing that is often overlooked when moving your data to a hosted cloud location is the ability to support network outages (offline mode). For some, this might be a very short-lived experience, but for those that need to be able to have serviceable applications for longer durations when a network connection is not available, this blog is for you.
Support for an offline cloud architecture tends to be most prevalent in systems that involve a lot of geographically segmented sources of data. For example think of a collection of retail stores, doctor’s offices, or ships at sea. Anytime there are a number of locations designed to collect data from users that are spread out at various locations there are many more failure points involved at the network level. These outages might be an occurrence of a weather disturbance, network coverage variances, or even basic technical failures. Regardless, the case most of these business cases need to continue operations if the cloud is not currently accessible to them.
Risk Assessment
Determining what you might be risking when moving your data to the cloud without an offline model is important. Risk assessment might vary greatly for each project. So it is important to determine if a robust offline model is needed for each project or not. Here are some questions to address for each cloud project to help evaluate if you require a more robust solution to offline while moving to a cloud architecture.
Simple data sets and changes that are not critical may be supported offline with a custom-built solution. However, if the data set is complex and critical to the business the complexities of supporting an offline mode can be a much more difficult custom solution to build in-house.
Are all the changes on your data set performed at your on-premise applications and sent to the cloud or are there ever changes made to the cloud that need to be distributed out to the on-premise?
Do changes need to be transmitted and visible to the other clients, if so can they still communicate changes with each other if the cloud is not accessible?
Does it need to be run manually or will it process automatically when connectivity is broken and restored.
Conflicts could occur if data changes are also made in the cloud to the same data sets.
Conflicts could occur if one client’s changes move through the cloud to other clients.
Are applications resilient enough to not disrupt the user experience and continue processing without loss of data if cloud connectivity is lost in the middle of a transaction?
How Replication Supports Offline
Once the risk assessment above has been done and you have determined if an offline architecture is required for your project, the next step will be to determine how the offline databases will be replicated with the cloud. This is where SymmetricDS comes in and has been built to solve this use case since it was originally created in 2008. Below are some of the factors that need to be addressed in order to properly support these offline databases.
If the persistence of data from your distributed applications is dependent on the cloud, the applications will not be serviceable during an outage causing a potential loss of data or a bad customer experience. Through the use of a local storage most if not all user services can be available even during an outage. The replication will then take on the responsibility to maintain all changes in and out of the local storage up to the cloud. This results in the best of both worlds where all data will end up in the cloud and the user experience is not lost during outages.
Sometimes offline architectures resulted in a nightly batching process that would allow the centralized or cloud database in sync only overnight when the systems were less busy and all the deltas from the day could be processed. This daily reconciliation of data is not optimal and often drove people away from even dealing with an offline model. It is important for your replication model in an offline architecture to be able to support changes in near real-time when there are no outages. SymmetricDS can be configured to deliver changes in seconds keeping a near real-time set of data in the cloud while still supporting outages.
3. Cost
So what’s the catch, how much cost will this incur? Ideally, the cost will have an intrinsic benefit after performing the risk assessment above because it was deemed necessary or critical enough to support an offline experience for the users/customers. However, costs might be reduced if a lightweight or low-cost database can be put in place as offline data storage. Databases such as SQLite, H2, Derby, MySQL, and Postgres can provide a no-cost option for this local data storage and will most of the time only be a temporary resting place for the data until it is replicated to the cloud. SymmetricDS supports all these various lightweight databases along with the ability to cross-sync them to the most popular cloud platforms.
If a network outage takes place or is happening repeatedly does the replication pick up and resume where it left off without user intervention? SymmetricDS supports this and will continue to try to re-establish connectivity to the cloud and once it does will transmit and receive all pending changes until the next outage occurs. This is all done behind the scenes without any user maintenance or intervention.
Summary
So even though an offline architecture might not be needed for all cloud solutions it is important to assess the risk properly of your project to ensure its success. Once the risk analysis has been done and it is determined that a cloud architecture that also supports an offline model is critical be sure to do the proper evaluations of your replication solutions. SymmetricDS has been in this space dating back to 2008 and has evolved into a premier solution for this use case.
Josh has worked in the IT industry for over 20 years as a developer, tech lead, and sales engineer. He has worked across a variety of businesses including retail, telecommunications, education, and healthcare. When he is not developing he enjoys whatever sporting event might be taking place.
Originally published at https://www.jumpmind.com.