What's Killing APM?

It's not precisely clear that the cloud is killing application performance management, but something is. It could be that cash- strapped IT teams whose application portfolios are changing rapidly can't give APM the time and resources to do it right, so they're using APM, at least as we classically have seen it, less and less. Then there are the tools themselves, which are notoriously hard to set up. And there's the rise of software-as-a-service and apps running from public or private cloud infrastructures. If you had a working APM methodology a few years ago, it has been broken by the use of cloud apps.

Whatever the cause, our October 2012 survey on APM shows the tech is now seen as less important than it was in our August 2010 survey (our full report will come later this year). Asked about the importance of APM in 2010, 50% of respondents said it was crucially important. That percentage is down to 42%. At the same time, survey respondents say their users are more tolerant of outages than they used to be. In 2010, 44% were extremely or somewhat tolerant of outages; today 47% are. They have to be: Those experiencing outages on a daily basis went from 8% in 2010 to 10% now, and those experiencing monthly outages went from 24% in 2010 to 27% now. This isn't a result most app managers would be proud of.

Assuming that our findings about outages aren't news to anyone, why is APM falling out of favor? In 2010, the reasons given for not implementing APM were: insufficient expertise to use the product (50%), high cost (41%), and it takes too much staff time to do it right (32%). Those are still the top three reasons for not doing APM, but the order has changed. Now a lack staff time heads the list, followed by a dearth of expertise and the cost.

As app environments become more dynamic and lifecycles for apps shorten, the substantial effort required for APM isn't worth the already iffy results it provides. And as teams slack on deployments, they get even poorer results, further devaluing APM tools. In 2010, 18% of survey respondents said their APM tool exceeded their expectations, down to 10% today. Today, there's a five-point rise in those saying APM products are falling below expectations. In a more detailed question, customer satisfaction with a range of APM functionality was down.

This would all be bad enough news if the APM product dissatisfaction was isolated to IT pros. But the dissatisfaction with executive dashboards is even more acute. In 2010, 21% said they were extremely satisfied and 41% somewhat satisfied with such dashboards; that's down to 12% and 32%, respectively.

It's tempting to blame the cloud, but the fraction of apps reported to be running "in the public cloud" is about the same as it was in 2010. It appears that APM simply doesn't provide the bang for the buck, and so not using it isn't seen as an impediment to adopting applications of any sort. We asked specifically whether the lack of APM tools is a barrier to wider use of cloud apps. In 2010, 49% said it wasn't a barrier; 61% say it isn't a barrier today.

One area where APM tools definitely have let IT pros down is in keeping up with complexity. As apps take a more service-oriented design, the task of setting up an APM tool to give anything close to meaningful information is much harder than it used to be. As one survey respondent put it: "There is a major conundrum related to the real-world use of APM tools. They work quite well in a static infrastructure environment. Unfortunately, current APM tools do not work well in dynamic Web services, and public and private cloud-based infrastructures, since they depend on statically defined relationships. By the time these relationships are defined to the APM tool, they will in all probability be obsolete, thereby negating the value and relevance of the APM tool."

The failure of APM software vendors to keep up with user needs is breathtaking. Because the nature of app life cycles has changed so profoundly, APM as a third-party product has outlived its usefulness for most environments. Service component deployments with their own self-health reporting capability should be preferred.

InformationWeek: Nov. 12, 2012 Issue

Download a free PDF of InformationWeek magazine
(registration required)