Yesterday we described Infrastructure Performance Management (IPM) and Application Performance Management (APM), and explained that the same performance management processes apply to both views. This may lead you to believe that they differ in objectives but not in substance. Wrong. Although the same processes apply to both, the information they generate is very different. Let’s compare the types of information that each view provides.
Incident Management
IPM Information: Router down, circuit failure, server out of service, group of servers are off-line, etc. These incidents are clearly attributable to infrastructure and affect many users in a wholesale fashion.
APM Information: Loss of service within a geographic region, execution errors (e.g., HTTP 404), slow performance, software incompatibility (client and server versions failing to communicate), missing cookies, users can’t acquire address or credentials, etc. Here the incidents are more focused on one user or a narrow group of users. Often they result from a user path misconfiguration within an otherwise healthy part of the infrastructure.
Availability Management
IPM Information: Percentage of circuits, routers, switches, servers, etc., that are operating. Availability reports are often the inverse of corresponding incident reports. If an infrastructure group – like switches – has no incident reports, then it is 100 percent available.
APM Information: Percentage of authorized user access methods (wireline, cell service, WiFi) that are working, number of client-server connections that can be made, all devices on a flow path are operating, SSL keys are installed and certified, alternate routing is working, etc. This view of availability is more subtle. A device can be operating yet a user of group of users cannot successfully interact with the system.
Capacity Management
IPM Information: Is there sufficient processing power in each system element to handle the projected load? This is often defined by the utilization and projected utilization headroom of physical resources like CPU, memory, circuit bandwidth, etc.
APM Information: Are there sufficient server process and TCP connection pools, and are latency and loss low enough to meet application needs? Is bandwidth management per flow, flow-based precedence handling, and traffic policing sufficient to keep critical business traffic flowing, etc. Most of this capacity management makes sure that the resources are not arbitrarily held back (e.g., when users see poor performance because they are contending for a token permitting access to a resource while the resource is sitting idle).
Service Level Management
IPM Information: Detailed description of services performed like number of transactions processed, web pages delivered, GBytes of traffic moved, files replicated, etc. These are service levels defined within a service offering description. Some of the IPM availability data may also be part of the service level report. The primary objective of these reports is to justify the cost of the service (internal budget or external vendor payment).
APM Information: What application flow characteristics are known and supported, do user response times support the business function, do voice services meet quality standards, does videoconferencing support business functions, etc. The primary objective of these reports is to justify that the service meets the needs of the business.
