Going on Autopilot - Nastel application performance management
Charley Rich, Nastel VP Product Management and Marketing, spent some time chatting with me about application performance management, queue management and how important this has become in an extreme-transaction-processing world. It was a very engaging and interesting discussion. What prompted the contact was Nastel's plans to present AutoPilot ® Application Performance Management Suite At IBM Impact 2011.
Where we've come from: A mainframe world
Transaction systems used to be designed as a monolythic block of code that worked with a transaction monitor and a database engine of some sort. While these could be quite complex environments, everything was supported by a single mainframe. Because they were running on a single system and the components communicated with one another by passing messages back and forth, it was significantly simplier to detect, isolate and then fix problems in application or database design that produced application slow downs or failures.The next step: Enter Midrange systems
As midrange systems became lower cost options, these applications were moved, largely unchanged, to VAX, PR1ME, Data General, IBM Series/1 or other midrange systems. A single application would reside on a single machine. Dealing with multiple systems in different data centers increased the level of complexity overall. Since any given application was still on a single system, it still was straightforward to find and fix problems.Industry standard systems arrive
As the industry increasingly deployed transactional applications on herd of industry standard X86 systems, the concept of a transactional application was exploded into multiple tiers of services, each running on its own bank of systems. Systems in each of these tiers might reside in different data centers, be running different operating systems and be products of different manufacturers. The level of complexity rose dramatically.Data centers have become computer museuems
None of those applications, regardless of whether it was hosted on a mainframe, a midrange system or a herd of industry standard systems, were decommissioned as this evolutionary process took place. New applications were added to what was already running in the data center. Now the overall environment is managed by separate teams of people, each managing a component of an application. They often don't speak with one another often.A glitch arrives
All it takes is for one component to suffer a "performance glitch" and an important workload can become unavailable. Sorting out what happened, when it happened and fixing it can be an overwhelming task. Unless the organization set up cross group processes for such a problem, simply getting the right people on the same call or in the same room might be a significant problem in itself.Nastel AutoPilot
Nastel's AutoPilot watches the queues that help the application components communicate with one another. It watches for potential problems and helps IT administrators know what is happening quickly enough that the problem can be prevented regardless of where in the complex environment it is occurring. It can watch queues on mainframes, midrange systems and even industry standard X86 systems.AutoPilot has been programed with a great deal of knowledge of how all the components fit together and what depends upon what. Patterns of activity can be established and then detected before they turn into problems.
Snapshot analysis
Nastel, along with CA, BMC and a few others, are offering products to address the complex world we find ourselves in now. While Nastel's products appear very strong and offer solutions for many organizations, the solutions offered by others also have similar profiles.All of the suppliers speak about the benefits of their products using similar messages making it difficult to distinguished one from another.
Nastel's predictive identification of problems combined with the products complex event processing are features that cause AutoPilot to stand out from the bunch. Although I haven't examined the product's code on a line by line basis, I was impressed with the description of what is being done to address application performance issues before they become problems.