Why is application performance management such a hot space when it used to be considered a solved problem?
It was a solved problem for a while, and it could have stayed that way--if only IT departments had remained happy with the old method of running their environments. Only a short time ago, an applications environment consisted mainly of a single, large server talking to a single, large database. Monitoring such an environment usually involved nothing more complicated than keeping tabs on CPU and infrastructure health. It was in those scenarios that legacy
APM vendors thrived and grew into profitable organizations.
But then something changed. As Gartner puts it in their 2010 Cool Vendors, IT Operations report: A few years ago, applications became business services built out of multiple distributed pieces. In other words, Service-Oriented Architecture started to take hold. When IT departments rebuilt their environments around SOA, applications found themselves in a brand-new world. Where there used to be one tier per application, multiple tiers sprang into being and created a whole new level of complexity.
As a result of these factors, the application environment is now dynamic. Its changing, not static. It can expand and contract on a dime.
So now the mandate for application performance management has changed:
Follow the business transactions. Regardless of how far-flung and distributed the application, it can be monitored and managed if the
application performance management strategy retains a tight focus on business transactions. What happens when the end-user adds a book to a shopping cart, or if a third-party company transmits mortgage paperwork through the applications API? Monitoring these events tells the IT Operations team whether the application is meeting is performance levelsor if problems exist that require immediate attention.
Apps are now dynamicAPM needs to be too. Manually instrumenting an application environment no longer works. Any
