Why use an agent as opposed to Horizontal discovery? or, Vice-versa.

[doug_schulze]

Had the very privileged opportunity to be a part of a recent fantastic webinar hosted by two of the greatest champions for ServiceNow Visibility (among others) Steve Emerson @sremerson and Severin Launiau @SeverinLauniau . I, along with my Discovery BFF and ITOM Heath Viceroy Ryan Zulli @Ryan Zulli were invited to answer questions in the background for our latest, greatest, and incredibly welcomed capability of being able to execute application patterns for classified app  CI's as Horizontal Discovery (Hz) does in its good work. Was an incredible session and highly recommend you watch the replay if you have the time.

During this event, there was one question that was posted about the possibility of replacing Horizontal Discovery with our Agent based solution now that near full application discovery (vCenter Hz API discovery is still probe/sensor based) would be available, and another asking if we we were going to have Agent-based discovery be the primary choice of 'Discovery'. Was very hard to not let my fingers fly in basically having to type an entire blog post of a response for something that has so many different possible answers, basically, it depends 🙂

As I've been known to say, "I've been doing 'Discovery' since it was a twinkle in Fred's eye". And as I started to represent our fantastic product one of the key things I would highlight is knowing what you know and knowing what you don't know. Being that we were solely agent-less in an agent-based world at the time I was able to make the compelling argument time and again that it was great that you know systems that you deployed an agent on, but what about those systems you 'don't' know about? It was a factor that made our product stand out. While we faced the credential challenges like in everyone's company silos it helped show again that we could help tell them what they don't know when Discovery was allowed to be at its best. 

Without exaggeration, I was on one engagement that the exit criteria is that Discovery needs to populate 80% of their known records. After 3 weeks of the deployment, we found 120% of what they thought they knew they had. This was a very powerful message to our Hz capabilities.

But it wasn't for everyone, there were times that due to local absolutes, there was no way in Hades that we were going to get credentials or access to critical environments...But...If we had an agent...My meek reply? Well, we have this .js script....you might remember the WMI Script and frown along with me 🙂

Well now we do have a proper agent and now it's coming into its prime and is going to bring a lot of good. Being able to scan IP ranges in an agent-less manner (Hz Discovery) gives you the big picture of your environment while deploying the agent which can fill the gaps that you can't see by process or logistics helps tell the whole story of your CMDB.  Bottom line? Building good processes around the agent's deployment can open doors to restricted environments, with live assistance to remote workers or systems are all valuable keys to any business process. You get to see what you know, and what you don't know.

Speaking of which, added bonus, remote workers. In Hz Discovery we need folks to be connected to the network to be discovered. Now with agent-based Discovery, you can load the agents and have them report directly to a MidServer securely be it in a local DMZ with an internet-exposed web services port or as Ryan and I messed around with, multiple mids behind an AWS ELB. Think about the possibilities for scalability and accessibility.

All in all, many may have a different recipe for making their CMDB (thank you IRE Team) but these two tools within our own Visiblity product make for a great partnership... when it depends 🙂 .