Some of you know that the Vallum technology and the Vallum Halo
Manager itself utilizes an installed agent for some metrics and
capabilities, but you may not know why we went in this direction and
thought process behind it. I have been asked the question on a few blog
last year. Hopefully this information will help you make informed
decisions if you are in a selection process for a network monitoring
solution or any solution where an agent is to be used.
occasions, so I thought I would spend some time on this topic and
explain the ins and outs of it. I also touched on this in a previous
Before you can really begin to understand agents, the first thing you have to cut through is all the misinformation and agendas that are out there. You will commonly hear from vendors that their solutions are agentless, as if this is some badge of honor or big positive. They will tell you that agents have huge resource overhead and they will crash your systems, and we don’t use them so our solution is better. But let’s step back a moment and examine exactly what they saying. Are agents as a category inherently bloated with the tendency to crash your systems? or are many just written poorly? While there is most definitely a very specific artistry to developing agents, at the end of the day they are generally no different than any other software. If you have a web browser solution that is constantly crashing and eating up the resources on your computer, do you blame web browsers in general or do you blame the vendor that developed it? Of course it is the vendor’s responsibility.
The reason that many software vendors bad mouth agents is that they themselves are not very good at writing them. Many took a stab at developing them with poor results. In addition, the agents ended up being single purpose, only able to function with their solution. If you had three agent-based solutions, you had three agents installed on your platform. Organizations pushed back on the poor quality and multiple agent installs. This is why many vendors deviated their solution focus towards an agentless approach with negative information about agents to try to make it a positive. To be quite honest, there is an artistry to writing agents, as I previously mentioned, and it is frankly not a competency that many vendors possess or want to possess. The agents are a less visible sub-component of their core solution that needs to be maintained in conjunction with it. It is not something that vendors generally focus on or directly sell, although this does not stop many of them from selling their agents as an expensive line item. The poor agent quality combined with the cost leads many to erroneously avoid agents in favor of less functionally capable agentless approaches.
So now that we have hopefully cleared up the miscommunication around agents, what exactly is the value proposition of agents vs. an agentless approach? A well written agent will be much more flexible given its direct presence and interaction with the platform and its services. It will have access to a greater number of metrics and granular data that are much more accurate and timely. The presence of the agent on the platform can provide remediation capabilities such as killing processes without the addition of external scripts. The agents can also function independently if communication is lost with the platform, which also allows processing to be decentralized across the enterprise, providing scalability that is not possible otherwise.
Agentless approaches on the other hand are reliant on analyzing network packets flowing across the network and utilizing existing exposed APIs on the platform. Packet capture and analysis can be very resource intensive not only for the network, but also the solution that is doing it. While it can provide data on service performance and availability, it cannot provide deeper more granular data on the platforms themselves.
Agentless solutions typically rely on polling technologies such as Simple Network Management Protocol (SNMP) and querying Windows Management Instrumentation (WMI) for specific server metrics, neither of which the vendor has any control over. With SNMP, it is not simple and you only have access to the data that the vendor on the platform has provided, and it cannot easily be modified or extended. WMI is specific to the windows platforms. Neither method will provide the metrics that can be obtained by an agent, and each come with their own complexities and security risks. Finally, both methods may or may not be implemented in an environment, and this process can be quite time consuming.
So this leaves us with two important topics. Charging for the agents and making them closed and single purpose. Agents are generally not a main selling point of solutions that utilize them, but they are the single point of enablement for the solution. The agent has to be installed before you can manage the platform. By charging for the agents, the vendors are simply crippling the rollout of their own solutions. Instead of buying 500 agents, a customer may only buy 250 of them. The closed, single purpose nature of the agents places organizations in an unpleasant position. If they have three agent-based solutions, they will have three agents installed on their platforms.
At Vallum we were painfully aware of these issues and this is one of the reasons why we partnered with the GMI-Foundation to utilize their GMI-Agent. The "GMI" stands for General Management Interface, and it is open and free to use. Vallum's version is called the Halo Agent. The Halo Agent effectively addresses the issues of cost, complexity and agents being closed and single purpose. To that end, Vallum recently announced the release of a software development kit (SDK) for developing applications for the Halo Manager solution and the Halo Agent. The applications are called Halo Apps, and you can find a growing selection of them on the Halo App Store on Vallum's website. Halo Apps allow organizations to tailor the Halo Manager solution to their specific requirements. Halo Apps can be created in a few days or weeks depending on their complexity. They are modular and reusable, and they do not require end-to-end Q/A testing of the Halo Manager solution, so they can be developed and deployed quickly. The bottom line is that the multi-purpose Halo Agent along with the ability develop new functionality via Halo Apps, allow organizations to free themselves from bloated and inefficient agents from other vendors.
I hope this information has been useful to you, and as always I welcome any comments. Please check out Vallum Software and our partner the GMI-Foundation.
About the Author:
Lance Edelman is a technology professional with 25+ years of experience in enterprise software, security, document management and network management. He is co-founder and Director of Technology at Vallum Software and currently lives in Atlanta, GA.
Before you can really begin to understand agents, the first thing you have to cut through is all the misinformation and agendas that are out there. You will commonly hear from vendors that their solutions are agentless, as if this is some badge of honor or big positive. They will tell you that agents have huge resource overhead and they will crash your systems, and we don’t use them so our solution is better. But let’s step back a moment and examine exactly what they saying. Are agents as a category inherently bloated with the tendency to crash your systems? or are many just written poorly? While there is most definitely a very specific artistry to developing agents, at the end of the day they are generally no different than any other software. If you have a web browser solution that is constantly crashing and eating up the resources on your computer, do you blame web browsers in general or do you blame the vendor that developed it? Of course it is the vendor’s responsibility.
The reason that many software vendors bad mouth agents is that they themselves are not very good at writing them. Many took a stab at developing them with poor results. In addition, the agents ended up being single purpose, only able to function with their solution. If you had three agent-based solutions, you had three agents installed on your platform. Organizations pushed back on the poor quality and multiple agent installs. This is why many vendors deviated their solution focus towards an agentless approach with negative information about agents to try to make it a positive. To be quite honest, there is an artistry to writing agents, as I previously mentioned, and it is frankly not a competency that many vendors possess or want to possess. The agents are a less visible sub-component of their core solution that needs to be maintained in conjunction with it. It is not something that vendors generally focus on or directly sell, although this does not stop many of them from selling their agents as an expensive line item. The poor agent quality combined with the cost leads many to erroneously avoid agents in favor of less functionally capable agentless approaches.
So now that we have hopefully cleared up the miscommunication around agents, what exactly is the value proposition of agents vs. an agentless approach? A well written agent will be much more flexible given its direct presence and interaction with the platform and its services. It will have access to a greater number of metrics and granular data that are much more accurate and timely. The presence of the agent on the platform can provide remediation capabilities such as killing processes without the addition of external scripts. The agents can also function independently if communication is lost with the platform, which also allows processing to be decentralized across the enterprise, providing scalability that is not possible otherwise.
Agentless approaches on the other hand are reliant on analyzing network packets flowing across the network and utilizing existing exposed APIs on the platform. Packet capture and analysis can be very resource intensive not only for the network, but also the solution that is doing it. While it can provide data on service performance and availability, it cannot provide deeper more granular data on the platforms themselves.
Agentless solutions typically rely on polling technologies such as Simple Network Management Protocol (SNMP) and querying Windows Management Instrumentation (WMI) for specific server metrics, neither of which the vendor has any control over. With SNMP, it is not simple and you only have access to the data that the vendor on the platform has provided, and it cannot easily be modified or extended. WMI is specific to the windows platforms. Neither method will provide the metrics that can be obtained by an agent, and each come with their own complexities and security risks. Finally, both methods may or may not be implemented in an environment, and this process can be quite time consuming.
So this leaves us with two important topics. Charging for the agents and making them closed and single purpose. Agents are generally not a main selling point of solutions that utilize them, but they are the single point of enablement for the solution. The agent has to be installed before you can manage the platform. By charging for the agents, the vendors are simply crippling the rollout of their own solutions. Instead of buying 500 agents, a customer may only buy 250 of them. The closed, single purpose nature of the agents places organizations in an unpleasant position. If they have three agent-based solutions, they will have three agents installed on their platforms.
At Vallum we were painfully aware of these issues and this is one of the reasons why we partnered with the GMI-Foundation to utilize their GMI-Agent. The "GMI" stands for General Management Interface, and it is open and free to use. Vallum's version is called the Halo Agent. The Halo Agent effectively addresses the issues of cost, complexity and agents being closed and single purpose. To that end, Vallum recently announced the release of a software development kit (SDK) for developing applications for the Halo Manager solution and the Halo Agent. The applications are called Halo Apps, and you can find a growing selection of them on the Halo App Store on Vallum's website. Halo Apps allow organizations to tailor the Halo Manager solution to their specific requirements. Halo Apps can be created in a few days or weeks depending on their complexity. They are modular and reusable, and they do not require end-to-end Q/A testing of the Halo Manager solution, so they can be developed and deployed quickly. The bottom line is that the multi-purpose Halo Agent along with the ability develop new functionality via Halo Apps, allow organizations to free themselves from bloated and inefficient agents from other vendors.
I hope this information has been useful to you, and as always I welcome any comments. Please check out Vallum Software and our partner the GMI-Foundation.
About the Author:
Lance Edelman is a technology professional with 25+ years of experience in enterprise software, security, document management and network management. He is co-founder and Director of Technology at Vallum Software and currently lives in Atlanta, GA.
No comments:
Post a Comment