The preceding examples illustrate why Linux is both exciting and terrifying to enterprise IT decision makers. It's exciting because there are so many useful freebies that can help trim up-front software cost and terrifying because there is no single point of accountability for many of the key building blocks that comprise APM functions.
Unlike the application server and database categories, which are fully stocked with traditional (in other words, well-supported and accordingly priced) solutions from first-tier vendors, APM has largely been farmed out to the open source community. This is great if you're into hacking Linux to serve your own purposes -- all of the aforementioned open source tools fall under the GNU General Public License. It's not so hot if you need cohesion across a multitiered run-time environment.
Which brings us to the issue of application serving under Linux. With few exceptions, the majority of large-scale Linux projects involve the use of one or more third-party Web application server platforms. That's because there is no real native Linux application server facility, unless you count Web scripting languages, such as PHP.
So although vendors may provide rich APM tools for their respective environments, these tools still know little about what's happening below them at the OS level. By that same token, OS-level APM tools such as sysstat know nothing about the Web app server beyond that it is a process that can be tracked using the /proc pseudo file system. Contrast that with Microsoft's Windows Server platform, which offers a fairly robust application server environment from day one. Moreover, the run-time environments in Windows, whether they be legacy Win32/COM-based or part of the newer .Net framework, are wired together through a consistent set of APM plumbing.
It's this disconnect and lack of cohesion, coupled with the aforementioned accountability factors, that can short-circuit the Linux cost advantage equation and send even die-hard open source advocates running for proprietary APM frameworks.
So far I've explored the two extremes of the APM model: single-vendor, vertical integration (Windows) and multivendor/author, horizontal integration (Linux). Sun's Solaris Operating Environment Version 9, in its third major release of the past decade, falls somewhere in the middle.
On one hand you have Sun, the open source advocate: holder of the Java keys, proponent of heterogeneous Web standards, and most recently, Linux cheerleader. On the other hand, you have Sun, the classic big iron player: lots of great functionality but key pieces are tied to proprietary hardware platforms.
For example, Sun introduced a powerful new APM solution, Sun Solaris 9 Resource Manager, to complement its latest platform release. Resource Manager is an IT planner's dream; it provides detailed feedback on application resource usage, allowing system administrators to audit run-time behavior for health analysis, charge-back accounting, and more. Combined with the Sun ONE Studio 7 development environment, Resource Manager makes for a cohesive, end-to-end APM package that spans both native Solaris and J2EE application types.
There's just one problem. Both products were initially only available on Sun's proprietary Sparc processor platform, which meant you had to invest in both the company's software architecture and its hardware offerings to realize full APM benefits. (Resource Manager has since been ported to Solaris for x86 with Release 9.)