Ever feel like you're running blind, even with a costly and complex application performance monitoring system in place?
The problem is that APM mostly focuses on Web applications. But most IT teams are responsible for vital business applications that aren't Web based and that must be available pretty much 100% of the time--and by "available" we mean near-instant response, not taking 10 seconds to refresh a screen. Think about an inventory database that salespeople and partners depend on. It's extraordinary that many shops are still in the position of not knowing performance is tanking until the help desk lines light up. And if you can't proactively monitor mission-critical applications hosted in-house, you're going to be in worse shape if (or when) they start migrating to public cloud infrastructure services.
Most of the companies we work with have a good handle on how well their e-commerce applications and outward-facing websites are performing. Now the challenge is looking inward to head off problems with critical business applications before customers or employees notice.
The answer to doing that is using synthetic transaction monitoring for those in-house applications. While previously synthetic transactions were only for Web applications, leading APM providers, like those listed in our vendor comparison on p. 11, are starting to offer real transactional automation integration. The key word there is "starting." The information in our comparison is based on data provided by the vendors; we have not lab tested these systems, so caveat emptor.
We strongly suspect that most vendors are being, shall we say, overly optimistic in their assessments of their products' capabilities. Test in your infrastructure before assuming any APM system can support monitoring of internal applications.
What are we looking for? Instead of having to manually run a test transaction, you have a process do it for you at measured intervals. The system records the time to completion, perhaps even the time between different steps in the transaction. An operation suddenly takes 30 seconds instead of five seconds and that delay happens three times over a five-minute interval? You have a problem--and an email letting you know exactly what's up. Then, runbook or scripted automation sequences take a flagging application server, indicated by a transaction monitor, tear it down from the server farm, and add a clone to the pool. Now you can investigate without end users being inconvenienced. To do all that, you need to know it's down, and the application monitor will tell you in a better way than any other monitoring tool.
IT seems increasingly open to trying to achieve this level of automation. In our 2013 InformationWeek Virtualization Management Survey, which will be released in a few weeks, we delved into use of automation systems like Microsoft System Center, PuppetLabs, and Opscode Chef. While only 15% have this technology fully deployed, 40% are in the process. That's great news for IT and the business.
Of course, advanced automation builds on baseline key performance metrics, because once you know an application is malfunctioning, you need to know why.