Everyone has a DevOps strategy and Application Performance Management (APM) can give you an added edge. By monitoring the performance and availability of production applications and services, APM has been used for years by IT Operations to fight service disruptions and outages. APM solutions use many combined techniques, such as synthetic monitoring, real user monitoring, server monitoring and others to achieve this critical goal.
Synthetic monitoring proactively fires transactions from multiple locations, 24/7, to ensure service availability and performance. It proactively alerts the team to any developing performance issues, before they impact end-users. "Real user monitoring," another APM technique, does exactly what it says on the tin: by monitoring real user experience, another layer of protection and buffer is added, allowing Ops teams to react to developing issues. In fact, APM provides many root cause analysis capabilities and also predictive analytics capabilities.
Generally, the faster DevOps teams can identify and fix performance and availability anomalies and mitigate risks the better. Indeed, APM supports many DevOps implementation goals, such as ensuring continuous release cycles deliver continuously on the uptimes and response times users expect. But there is a catch: in performance management, the first question Ops ask when faced with a problem is "What's changed?" If this exact service performed well yesterday then why is it underperforming today? APM is designed to primarily answer this question.
Imagine a network node faults, maybe a database change causes it to underperform, or perhaps it's just Christmas and user numbers have tripled: APM is great at identifying and helping to resolve issues of this kind, but it gets trickier. Today's architecture is so distributed that often the root cause of a performance issue isn't even in the impacted service or application. There are many transitive problems that require high levels of sophistication to understand.
One prominent example I remember is a retail banking platform that suffered from dramatic performance degradation of its login function. It slowed to the point it began seriously affecting users, who started flooding the call center with complaints. Once logged in, everything was fine - but the login function just seemed to get slower and slower by the minute for no apparent reason.
It took almost a day for the team to learn a release on the mainframe side contained a change to the user lookup function, resulting in the issue. The mainframe folks didn't know their code was accessed in this way and the web team never imagined a change on the most back-end of systems could cause so much trouble.
The moral of the story clearly touches on some of the core pillars of DevOps: collaboration, automation, and sharing. Change information is clearly critical to APM teams, and as part of Automic's integration with CA, that was one of the first things we included.
We've integrated our Release Automation platform with the CA APM suite so changes made, anywhere, are always reflected in all relevant APM dashboards and timelines, immediately. We've also added a capability to avoid "false-positive" APM alerts that can occur during a deployment by extending Release Automation's orchestration capabilities to include APM as well. The synthetic monitor is switched off during deployment meaning it does not detect a service disruption during planned deployment activity and won't alert support teams to chase a non-event.
We've built an on-demand webinar which you can view on our new dedicated page.
