Identifying Four Gaps in Application Recovery, with Dreeze

Avi Raichel from Dreeze introduced the presentation by highlighting a critical issue discovered through interviews with over 100 enterprises: while most companies can recover their data in the cloud, the application itself often remains non-functional, hindering business resumption. He noted that data restoration is considered “table stakes,” but the actual application recovery process is complex, manual, reliant on specific human knowledge, not repeatable, and can take days. This lack of confident, swift application recovery capability creates a significant challenge for CIOs in assuring resilience to their boards.

Avi then detailed why cloud-native applications present this challenge, illustrating their intricate architecture involving hundreds of interconnected resources across network, identity, data, and application layers, along with external service dependencies. This complexity creates four key gaps in application recovery. First, a “knowledge gap” exists because it’s hard to know the application’s true composition, with constantly changing dependencies, scattered documentation, and no single live application map. Secondly, there’s a “protection gap” where only data is typically backed up, leaving the crucial infrastructure, application configurations, and third-party connectivity unprotected.

This creates an “orchestration gap” during recovery, as rebuilding an application becomes a manual, improvised effort dependent on specific individuals, often involving outdated runbooks and trial and error during critical incidents. The lack of an automated sequence means recovery takes days, not hours. Finally, a “validation gap” arises because the manual and difficult nature of recovery makes testing infrequent, turning each test into a significant project. This infrequency means companies lack current, reliable SLAs for recovery, essentially operating on “hope” rather than proven resilience. Collectively, these four gaps prevent customers from effectively recovering their cloud-native applications.