APMdigest asked the top minds in the industry what they feel is the most important way Application Performance Management (APM) tools must evolve. The recommendations on this list provide a rare look into the long-term future of APM technology. Part 6, the final installment of the list, covers development and DevOps.
Start with 30 Ways APM Should Evolve - Part 1
Start with 30 Ways APM Should Evolve - Part 2
Start with 30 Ways APM Should Evolve - Part 3
Start with 30 Ways APM Should Evolve - Part 4
Start with 30 Ways APM Should Evolve - Part 5
25. MICROSERVICES
Docker is going to disaggregate applications into hundreds and thousands of micro-services each of which will communicate with each other over virtual networks. APM tools need to evolve to technically step up to be able to monitor 100X or 1000X as many things and the transaction flows across those things as is the case today.
Bernd Harzog
CEO, OpsDataStore
We need to not only be able to understand the status of individual microservices, but also the state of the holistic microservice architecture itself as the complexity shifts from the internals of the application or service to the accelerating number of interdependencies. Understanding this latter perspective has been a challenge for even the most experienced of Web-scale firms.
Cameron Haight
Research VP, IT Operations, Gartner
26. API MANAGEMENT
APM providers are evolving to be one stop shops for all things application performance. Customers too are looking for solutions that fit well in their NOC or IT ecosystem. Over the years, we have learned, that any ecosystem play is impossible without a sound API strategy. As more tools enter the ecosystem, more APIs will be offered. Monitoring and managing the performance of those APIs will be critical to ensure the ecosystem harmony. As for the APM ecosystem, it's about time we start rethinking the conceptual APM framework and include API management and deep monitoring as an essential piece of APM.
Priyanka Tiwari
Product Marketing Manager, AlertSite, SmartBear
27. THE ENTIRE STACK
The introduction of RUM in the web performance world was a disruptive force. It was clear that occasional synthetic checks from a few locations around the world were wholly insufficient in understanding the behavior of web applications. I see the "RUM-trend" driving its way down stack. Synthetic checks against APIs, databases, micro services and even disks will slowly be displaced by the observation, recording and analysis of every single transaction. You will be able to profile every IOP on every spindle in your whole data center second by second – and people will wonder how we lived without before. We're close.
Theo Schlossnagle
Founder and CEO, Circonus
28. SSL DECRYPTION
With a high percentage of business applications now encrypted in SSL, decrypting SSL is imperative for effective APM. Given the high processing power required for SSL decryption that eats into the processing capacity left over for APM, organizations are best served by having a purpose-built network visibility solution offload SSL decryption from the APM tool.
Ananda Rajagopal
VP - Product Line Management, Gigamon
29. INTEGRATION WITH TESTING
One of the challenges with APM is to gap the chasm to performance testing and continuous integration. Load testing and APM need to work well together to enable the full vison of DevOps, but very few vendors have found a way to automate findings in APM to relevant tests and vice versa.
Sven Hammar
Founder and CEO, Apica
30. SUPPORT FOR CLIENT-SIDE TECHNOLOGY EVOLUTION
Going forward, the most successful APM Vendors will be those who create and sustain competitive advantage based on effective support for client-side technology evolution, for example RUM refinements to support Single Page Applications or synthetic test visual endpoints. As always, most benefit will be delivered by accessibility/usability rather than "tick the box" support.
Larry Haig
Senior Consultant, Intechnica
If you have additional ideas about the evolution of Application Performance Management, send a blog to APMdigest.