As you’ve no doubt heard, we’ve been acquired by CA, which, a few years ago, acquired Wily Technologies, which also has products in the field of “application performance management.”  Earlier today, there was a meeting among us to discuss similarities and differences between CA|NetQoS’s approach and CA|Wily’s.

And one of the things I noticed is that, ultimately, both our stuff and their stuff has the same goal, and in many ways, the same design philosophy.  We both knew that passive monitoring tools that can scale with the network and infrastructure were the way to go, and we were both trying to get down to the source of application slowdowns for quick resolution.  So from a high-level messaging perspective it can be hard for the uninitiated to tell Wily and NetQoS apart. 

But there was a difference in our philosophies, and this really did become apparent in the way the programs were designed and used.  NetQoS based their software primarily around using the information available from what the network gives you, namely packet headers and NetFlow.  And while we can drill down to the packet level if need be, our primary function is to baseline performance and then inform you when things start to deviate from the baseline. 

Wily, so far as I was able to ascertain from the discussion (which, I’ll admit, went so far over my head that I’m pretty sure it’s eligible for a DARPA prize for unmanned orbital flight,) drills down into applications much further than NetQoS.  For example, Wily’s stuff can drill down not only to the application process which is causing problems, but can steer you to the individual line of code which is causing those problems.  (This is important when you have, say, a Java application, which is just running JAR files on otherwise identical Java virtual machines – the process could be running fine, but there might be a hiccup in Java interpretation.

What’s interesting to me is that the two philosophies tend to have come from the different backgrounds of the two companies.  NetQoS’s stuff is really designed to be used by the network engineer, giving information which allows you to drill down to find and diagnose the problem as quickly as possible.

Wily’s stuff seems more geared towards the (networked) application developer, the person who needs to know where the problem is in the code to fix it. 

I’m sure that to many people, getting two application performance applications may seem like having both Matlock and Columbo on the case.  And in a way, that is.  Columbo goes around solving pretty much all the crimes in Los Angeles to make sure they have the right suspect.  Matlock comes in when they know there’s a problem – namely, the wrong person’s been accused – and then gets down to the nitty gritty in order to fix the problem. 

I like ‘em both.  (I still think Columbo’s cooler, though.)