The resulting message is mixed. Sun pays lip service to the open source development model, but it tends to keep best-of-breed APM solutions close to the hardware home. Microsoft, with its hardware-agnostic, "we'll run anywhere it makes sense" strategy, looks positively transparent by comparison.
The fact that Sun is the source for all things Java is a double-edged sword: It gives them street cred with the open source crowd, but it also raises customer expectations regarding Sun's strategy and behavior. If Sun really wanted to demonstrate openness, they would port the majority of these
APM products to Linux (promises have been made) or at least make them consistently available for Solaris on x86. However, things are improving with Release 9.
Meanwhile, IT shops need to consider the potential for unforeseen proprietary tie-ins when evaluating Sun's APM strategy. Such is the challenge when dealing with a vendor struggling to reconcile its role as an open source leader with the need to move high-margin, big iron hardware.
Shaping an APM Strategy
I said at the outset that the platform with the most cohesive APM facilities would likely also make the most sense economically. Thanks to a predilection toward bundling extra functionality with its OS releases, Microsoft wins this argument hands-down.
But base OS functionality is only part of the APM equation. In many situations, a single-vendor solution may not be a viable choice given an organization's installed base, for example bringing Microsoft's Windows-centric model into a shop full of legacy Unix boxes.
Thankfully, a plethora of third-party APM tools promises to make sense of the chaos … for a price. I'll take a look at some of these tools -- specifically, those geared towards custom application development and instrumentation -- in future articles.