With more applications hosted in more places in more complex ways -- with some parts running in one place, other...
parts elsewhere -- it's no wonder enterprises are having trouble telling how well they are doing delivering critical services.
Many enterprises now have returned to the point where their first inkling that there's a problem is when a client or staff member calls to complain (or, worse, tweets about it).
As a result of this shift in application delivery, enterprises need new tools to manage apps. The latest application performance management (APM) tools are designed to cope with a hybrid service-delivery environment that is heavily dependent on east-west flows among clouds of service components.
In the right place
One key feature of new APM environments is the ability to have instrumentation where it is needed: near the services. There are a variety of ways to accomplish this:
- Within a hypervisor environment, monitoring both response times and resource consumption for VMs in the space;
- Where there is no hypervisor (as with dedicated physical servers) or where the hypervisor is out of reach (that is, in an IaaS environment), running on an operating system;
- Inside a container;
- Inside the application server environment for Java or .Net;
- On end-user devices, continually or on-demand with instant download.
For internal services that talk to external services to pull together a response to a client or customer, monitoring on the in-house component that talks to the external sources has to provide intelligence on performance.
And of the right size
Given the need to put performance probes in anything from a hypervisor down to an application server, lighter is going to be better. Footprints should either be small across the board or should scale down to match the scope of their monitoring task. Larger will be fine for something watching everything in a hypervisor space; smaller is beautiful when we're wedging the monitoring into a Tomcat instance or a cell phone Web browser.
That are smart everywhere
The distributed monitors shouldn't be passive, simply feeding large streams of information to a central hub somewhere. As much as possible, each application monitor should be capable of performing initial data analysis, sending up compact metadata streams on a continual basis unless tapped by the central management unit to transmit more detailed info. The larger the scope of the application performance management tool, the more pre-digestion it should be able to do. The central controller should provide broader and deeper analytics, and be able to tweak the behavior of the probes based on what is happening.
The ideal APM tool will actually take steps to manage performance rather than simply monitor it. This can be done in several ways:
- Via changes in load-balancing behavior
- Through changes in traffic-shaping policy
- By dynamic provisioning and deprovisioning of resources
If the tool is itself not capable of doing one or more of these things, it should at least be able to trigger the necessary action using the APIs on tools or services that can, or it should be able to alert an orchestration tool that can drive the adjustments.
In the age of "consume anywhere, serve from everywhere" services, IT needs new levels of visibility and control on performance. By combining new generations of tools architected to operate in the hybrid service environment with existing management consoles and dashboards, it can get what it needs.
Read more about APM from this Essential Guide
Learn the latest about mobile APM.