Blogs

RedMonk

Skip to content

More on nVision Software's AppVision

I talked with nVision Software’s Juan Cabezas and Ted Hulick yesterday afternoon to get a more in-depth technical overview of how nVision’s AppVision works. (Thanks to both of them for making the time ;>)

Ted seemed quite passionate about systems management and, having been in the industry for for a while, is very eager to “do things right this time.” Technical passion for systems management can be hard to find, and it’s key for up-and-coming companies: otherwise, you might end up with the same old thing.

Beyond Instrumenting

nVision Functionality

Here are some highlights:

  • From the discussion that we had, it seems like it’s technologically quite clever. On the Java side, there’s classloader magic that allows AppVision to do light-weight instrumentation, in runtime, or VMs. The .Net technology is a bit thornier apparently as .Net runs with more security options on by default (most Java apps don’t go hog-wild with SecurityManager) and there’s apparently more hidden voodoo in .Net than Java.
  • Relevant to the current open sourcing Java discussion, Ted said that access to the Java source over the years (before it being technically “open source”) has been great.
  • Their overall systems management philosophy was along the lines of the New Systems Management think that I’ve been seeing. In the words of Ted: “no metrics.” There’s, of course, over-statement in that. The point isn’t that there are absolutely no measurements or measuring going on. The point is more to value judgments and conclusions over raw data.
  • There’s an emerging world of non-traditional devices, like VoIP phones which are essentially just little computers — that are beefy enough to run Java and .Net. Meaning, there are new types of devices to monitor and manage.
  • While BCEL is “fine,” nVision wrote their own byte-code library to get complete control over that core part of their stack.
  • AppVision is built on a plugin architecture.
  • The “symbiont” (the code that AppVision runs in the host VM or CLR) can be cut down to a few 100K. This is important, of course, for using less than, as Ted said, 5% or less of the host’s resources. With that AppVision to target not only desktops and servers, but the wider range of devices mentioned above in addition to realtime systems.
  • Along those performance lines, AppVision doesn’t do method-level tracking. Instead, it pays attention to explicit error states (like exceptions) and only instruments key parts of the application (like the main() method/class).
  • We talked a fair amount about scaling at the database level and scaling in general. That’s encouraging, of course, because scale is the mid-life crisis of all systems management tools and platforms.

We of course covered more detail. The AppVision 5.0 page actually goes into a fair level of detail as well.

In the Labs

Overall, my theory is that AppVision would be a great “debugging in the field” tool. I’ve longed for a “headless profiler” for sometime, and the approach that AppVision has taken might shoe-horn into that. We’ll see.

As the use of the word “theory” implies, all of this discussion comes with the disclaimer that it’s just been discussion up to this point, I can’t vouch for nVision and AppVision beyond that. Also, I still haven’t tried the application out on my own, but I should be getting an evaluation/demo copy sometime soon. I’d be interested in any “tests” or “scenarios” you, dear readers, have in mind.

Tags: , , , , ,

Categories: Java, Systems Management.