At JPMorgan Chase & Co. headquarters in New York last week, the world's most influential investment banks and software companies unleashed a disruptive new technology that will change enterprise software and application performance monitoring forever.

This new technology is an open, interoperable protocol for business messaging called the Advanced Message Queuing Protocol - AMQP 1.0. It's disruptive because it allows anyone to build the kinds of powerful applications that only investment banks could afford to build – and to do it quickly, without specialized programming skills.

AMQP 1.0 allows ordinary companies to automate complex business processes, just like investment and trading banks do, without writing applications from scratch or investing in lengthy integration projects. You can source services and components from any vendor or service provider and confidently assemble them into new applications that are both highly capable and highly reliable.

Imagine a new smartphone app that gives your sales force complete visibility into your distributed supply chain so they can delight your customers by telling them exactly when they'll receive their order. Imagine connecting cloud-based services, components from multiple vendors, and your own business logic into a seamless, flexible application environment that you could never afford to build on your own.

APM in a Brave New World

Now, imagine trying to manage application performance in this brave new world with your existing tools ...

- Traditional instrumentation approaches (where you drop agents on servers) won't provide the coverage you need across dozens of diverse platforms and components you don't control.

- Traditional measurement techniques (where the APM system monitors “units of work” within each application component) won't work when the internals of the various services are opaque or inaccessible.

- Traditional application models (where you can divide things neatly into 3 or 4 tiers) won't handle the complexity and dynamic transaction flows in highly-distributed applications.

Here's what will work: A new approach to application performance monitoring that embraces and manages the complexity that interoperability creates. Your requirements list should include:

- Vendor and service provider agnostic instrumentation mechanisms. Meeting this requirement is easy using network-based packet capture approaches, as AMQP 1.0 is an open, standard protocol that can be seen on the network.

- Measurement techniques that analyze the external behaviour of a component instead of its internal workings. Meeting this requirement involves analyzing, and more importantly, understanding the application layer information. And now, we have our first point of tension. Very few network-based monitoring systems can cope with the complex syntax and semantics found in the application layer. But, application-based systems can't fulfill the first requirement.

- Rapid navigation through the various hops and layers of complex transaction flows to allow rapid identification of slow and failing components. Fulfilling this requirement demands a multi-hop transaction correlation capability commonly found in Business Transaction Management solutions. And now, we have our second point of tension. Very few BTM systems monitor at the network layer.

- Ready access to real-time performance data that you can feed into event management and automation systems. Meeting this requirement demands an APM system that can handle several orders of magnitude more processing than any single application component. If your application has 5 transaction hops and runs at 500 transactions per second, your APM system has to handle 2,500 transactions per second and a minimum of 10,000 messages per second for simple request/response transactions. And now, we have our third point of tension. Very few APM systems are designed to handle this kind of volume.

So as you start matching your list of requirements to the available products, you'll quickly realize that most APM systems are designed for different applications than the ones you want to build using AMQP. They're designed for tightly coupled three tier web applications, proprietary mainframe messaging applications, or Java-based OLTP applications. They aren't designed for highly-distributed, multi-vendor applications. A new, transaction-centric approach to APM is needed to monitor AMQP-based applications.

Interoperability will change everything. Including APM.

For more information on AMQP 1.0, check out this video from Loki Jorgenson, INETCO's Chief Scientist:

About Marc Borbas

Marc Borbas is the Vice President of Marketing for INETCO. In his role, he sets product strategy for INETCO Insight, the company's flagship business transaction management product. Borbas was a catalyst behind INETCO's adoption of AMQP 1.0 within the core architecture of the INETCO Insight real-time transaction monitoring product.

Borbas has worked in the applications and infrastructure software space for more than 12 years, and has an extensive background in marketing, business strategy and product development at Sophos, Business Objects (now SAP), Crystal Decisions, and Fincentric Corporation.

Related Links:

www.inetco.com

www.amqp.org