Six levels of cloud offline capability
The cloud is currently the preferred operating model for running and providing applications. However, if the connection between the client and the cloud fails, the cloud-based applications are no longer operational.
This risk can be accepted as unlikely. On the other hand, it is more economical and sustainable to consciously foresee and plan for connection failures and take measures based on them. This increases customer satisfaction, enables use in additional situations and increases the added value of cloud-based applications.
The Cloud Offline Capability Model explains six functional levels of the offline capability of a cloud operating model. For each level, it specifies functional, methodological and technical concepts for its implementation.
- Cloud Computing
The cloud operating model provides for data processing resources to be made available as required. The resources are primarily divided into computing power and data storage. Users do not have to actively manage these resources.
- Business Information Systems
Client-server applications for operational information systems are closely interlinked with operational business processes. They support them or make them possible in the first place. The applications are designed to generate, process, retrieve or delete business-relevant data.
- Goal: Exceptional user experience
Cloud-based applications that are explicitly tailored to offline situations offer an outstanding user experience. This user experience is not only interesting for traditional customers, but also for all employees of a company. Satisfied customers are loyal customers, satisfied employees are more productive.
Challenges
- Toggled Virtual (Private) Networks
In particular, access to company-owned cloud environments is usually carried out via a VPN connection to ensure a high level of security. If the VPN connection is switched off, cannot be established due to the current environment or components are incompatible due to different versions, this leads to an offline situation.
- Switched Mobile Network Cells
Connection failures for mobile users can have several causes. If the users are on the move, switching between radio cells can cause a failure. The radio coverage may be too weak due to structural or geological conditions. All users in a radio cell also share the bandwidth; this can also cause connection failures or delays.
- Failed Network Components
Various components organize the network communication between the client and the cloud. The brief failure of a single one of these components can lead to a complete breakdown of the network connection. This does not necessarily have to be caused by the components themselves; external factors such as power failures or mechanical damage to the infrastructure are also risks.
Das msg Cloud Offline Capability Model
The msg Cloud Offline Capability Model defines six functional levels of offline capability. It starts with level 0, which is synonymous with a complete lack of offline compensation. Level 5, on the other hand, means that the application offers almost complete offline capability and there is basically no difference in operation for users.
The user experience improves with each successive level. The technical complexity increases at the same rate as the user experience. This means that there is always a trade-off between the desired or required user experience and the acceptable or feasible technical effort.
However, an application never has to be offline-capable in all aspects. For example, some use cases can be mapped offline sensibly, others not at all. Accordingly, each use case must be considered individually and the required degree of offline capability determined.
- L0: Offline Unaware
The client cannot handle offline situations. The application fails to start or operations cannot be completed during client operation due to an error.
Concept, method, technology: Thin client
- L1: Offline Aware
The client actively detects connection failures and explicitly blocks the user interface. It can also display modal error messages or simple notifications.
Concept, method, technology: Rich Client, Web API - Network Information API
- L2: Offline Read
During a connection failure, i.e. an offline phase, the client allows various read operations on the locally cached data. Write operations are not possible.
Concept, method, technology: Data Access Layer Proxy, Web API - Storage API
- L3: Offline Read & User-Exclusive Write
During an offline phase, the client enables atomic read operations on all locally stored data, but write operations only on user-exclusive, locally stored data.
Concept, method, technology: Data Synchronization, Last-Win Conflict Resolution
- L4: Offline Read & Atomic Write
Despite a connection failure, the client enables atomic read and write operations on all locally cached data.
Concept, method, technology: Conflict-Free Replicated Data Types (CRDT), Event Sourcing, CQRS, Optimistic Locking
- L5: Offline Transactional Read & Write
During an offline phase, the client offers users non-atomic, transactional write and read operations on all locally cached data.
Concept, method, technology: Saga, compensation pattern