Here is a brief summary of the most common approaches to application recovery since the mid-1990s, along with an overview of the limitations we’ve run across most frequently.
METHOD: Scripting
DATES: 1995 – Present
ALSO KNOWN AS: “Manual Labor”
WHAT IT DOES:
• Users identify problems and alert IT
• IT focused on infrastructure, not apps – at this time, there was a direct correlation between server and app, as all apps ran on dedicated HW (prior to virtualization and cloud), which no longer exists
• Difficult to pinpoint problems
• Heavy reliance on scripts--requires maintenance of script library
METHOD: Runbooks
DATES: 2001 – Present
ALSO KNOWN AS: “The Manual Process of Manuals”
WHAT IT DOES:
• Shelves of binders: if this, then that
• IT still focused on infrastructure, not apps
• Still difficult to identify source of problems
• Recovery very labor intensive
METHOD: Runbook Automation
DATES: 2007 – Present
ALSO KNOWN AS: “Rise of the Machines”
WHAT IT DOES:
• Emergence of software platforms that can execute scripts
• Works for routine operations such as provisioning
• Still requires a manual decision on what to do (which runbook to execute) – as it lacks awareness of overall health or current state of an application
LIMITATIONS OF PRE-APM APPROACHES TO APPLICATION RECOVERY
IT organizations manage run-time applications largely through an infrastructure-centric approach (network, server monitoring), which is then used to derive application health. The challenge with the approach is that it is not application-aware, and cannot tell you anything of the critical applications running on top of them. In some cases, application level monitoring is implemented, which provides analytics about an application’s performance. However, without the ability to intelligently respond, or empower staff to do so, these analytics will have limited benefit to ensuring the uptime of applications in their run-time environment.These tools tend provide a historical or root cause analysis view, versus a responsive solution to addressing real-time issues.
In conjunction with this approach, IT organizations may couple monitoring with script-based tools , including (also known as Run Books,) to help improve the efficiency of routine and pre-defined tasks. Scripts and run books can be effective to automate basic tasks with a known “start” and “stop”, however, they are not well-suited, nor are they scalable for complex, run-time environments. This is due to the fact that to address run-time Application Management with this approach, it requires scripts to be written for every possible scenario, and every possible combination of scenarios that may occur for each application – and they must be continually updated and adapted as the environment grows.
Furthermore, this typically still requires manual decision-making. And if scripts are not run properly, based on the state, and in context of each application’s hierarchy and dependencies, they provide limited utility – and in cases may actually compound the application downtime and data corruption problems they sought to prevent.
The App Hugger's Brief History of Application Recovery - Part II: The APM Era