Application Performance Management (APM) tools are hot right now – so much so that it won’t be long before APM reaches the same level of notoriety as the cloud, the IoT, and a personal favourite – big data.
Although we aren’t an APM vendor, we share the belief that applications should be put at the heart of your IT monitoring strategy – as shown by our Enterprise Application Monitoring (EAM) feature set – and for that reason we wanted to write a short piece that goes some way to explain why so many organizations are rightly adopting this new, exciting piece of tech.
Let’s start from the top; APM stands for Application Performance Management or Application Performance Monitoring and, whilst there are some ideological differences between the terms – with Application Performance Management suggesting more proactive approach and Application Performance Monitoring arguably sounding more reactive – for the most part they can be used interchangeably.
Application Performance Management typically means the active, on-going management of the performance, availability and, crucially, the end user experience of software applications. Conceptually, it means putting the end user experience at the heart of application management and this tends to go well with an agile, DevOps, continuous deployment methodology, creating a constant cycle of delivery, performance monitoring / measurement and improvement.
In terms of tooling, Gartner has defined APM as having to meet five core pieces of functionality;
More simply put, APM tools look to provide a holistic view of an application’s performance and surface the insights that can drive improvements to that performance. Those insights cover both current delivery of the application – for example, identifying that slow response times for users in Canada are due to issues with a CDN provider – and enhancements to the application software itself – say, identifying the poor SQL query which is causing slow checkout times for your users.
The diagram below, inspired by Matricis, offers an alternative take on the typical monitoring features that are synonymous with APM:
APM is used on actively-developed, “in-house” apps (as opposed to applications that were purchased via a third party) and is typically reserved for applications that are directly revenue-generating or are in some other way central to a business’s core function. In addition, these apps are very often ‘cloud-native’.
Given the enormous growth of web / app-centric business (Amazon, Netflix, Uber etc…), together with the digitization of almost all existing consuming-facing businesses (online banking, online shopping, online government services etc…), these vastly valuable/revenue generating apps need to be constantly available and without performance issues. And for those sorts of apps, APM is seriously big business.
One side effect of the growth of APM has been to make the world of application monitoring extremely uneven; leading vendors essentially target all their new tooling and features at a tiny percentage of applications, leaving the vast majority of apps, which aren’t appropriate for APM, left with often dire legacy monitoring tools.
The answer to this question is inevitably defined by what you’re looking to achieve. If you’re adopting a DevOps philosophy and are concentrating your efforts on one or two key applications, then APM is likely to be invaluable and there’s a rich and competitive vendor landscape at your disposal. For net new applications, APM represents an opportunity to bake application monitoring, measurement and improvement right into the core of your application delivery methodology.
If however you’re focused on a broader application portfolio, consisting largely of either third-party or legacy applications, then APM tools are likely to be either beyond your budget constraints or of little additional value. That doesn’t mean that you can’t take some of the core learnings from APM and apply them to your own monitoring efforts. After all, that’s where most of the innovation for the monitoring industry has come from in recent years.
For those not given the opportunity to bake APM as part of their application from the start, there’s a very strong use case to retrospectively add this tooling to high profile, revenue generating apps. Think about it. Downtime for an eCommerce store would be positively catastrophic – and examples aren’t exactly few and far between. Earlier this year, Amazon were estimated to have lost between $72 million to $99 million when their customers experienced connectivity issues for just over an hour. Yikes.
Avoiding outages like this is one of the main reasons businesses are turning to APM. Their prescriptive / predictive capabilities will often highlight issues before they impact the end user, and although these types of tools can be pricey, the opportunity cost will almost certainly be greater.