I have been consulting with clients for many years, and there’s one topic that comes up on a regular basis: should IT service management be agent-based or agentless? This can quickly become a heated debate, sometimes triggered by positive and negative experiences from the past, but also because of a new technology or new vendor stimulating the discussion.
Lots of articles have already been written on this topic—even on Wikipedia. So I’ll try not to bore you by repeating what’s already been said. Both alternatives have their advantages, so in this post I will suggest how you can use both technologies in combination to get to value quickly.
What is an agent?
When I refer to the term agent, I mean an agent code (typically a daemon) running on a managed system. Remote management would not require an agent running on a system, but obviously it would still have an agent running somewhere, typically a proxy or anchor server.
Comparing agent-based and agentless solutions
- Agent-based solutions typically provide richer, deeper management functionality.
- A running agent relieves the user from maintaining credentials.
- Many agent-based approaches have sophisticated solutions to traverse multiple firewalls and to control the flow of connection establishment.
- Agents can perform some activities autonomously, which is especially important for systems that are not always connected to the managing server (roaming systems).
- Frequently, agent-based solutions scale better because the agents and the management infrastructure provide additional logic and functionality for delegation and better scalability handling.
- An agent needs to be installed and maintained.
- Agent management and availability can sometimes become a challenge.
- There’s some overhead for the running agent on the managed system (CPU, memory, additional software).
- There is no agent to install and maintain.
- There can be less overhead on the managed system (CPU, memory, additional software).
- Sometimes agentless management is the only option available (for example, a hardened, locked-down system or device).
- Credentials have to be managed.
- Management functionality is limited to what the system exposes through interfaces (Windows Management Instrumentation [WMI], Simple Network Management Protocol [SNMP] and so on).
- Agentless management sometimes requires additional, unwanted ports to be enabled in the firewall (WMI, SNMP).
- Agentless solutions tend to put more load on the network with regard to the amount of data sent and amount of connections.
As you can see, often the pro argument for one approach is the con argument for the other. At the same time, there are arguments that apply to both worlds. For example, new instances have to be discovered in both cases, and you would either have to deploy an agent to these systems or manage the credentials to allow remote management for the new system. Another example is the fact that both solutions depend on a managing server being available. Sometimes agent-based management gives you more autonomy, but you still need a system that either instructs the agent or directly manages the system.
One size doesn’t fit all
There is not a single solution to address all of a company’s service management needs. Therefore it is important that clients have choices so that they can select the best option based on their business and technical needs.
In IBM Cloud & Smarter Infrastructure (C&SI), we provide clients with choices. For many management functions, we provide an agent-based solution as well as an agentless solution. Let me give you a few examples:
IBM Tivoli Asset Discovery for Distributed and its technical evolution IBM Endpoint Manager Software Use Analysis provide a highly scalable agent-based discovery. On the other hand, IBM Tivoli Application Dependency Discovery Manager allows an agent-based discovery and inventory of the IT landscape.
IBM Tivoli Monitoring (ITM) provides both an agent-based monitoring solution through ITM agents and an agentless monitoring solution (also known as ITM remote monitoring). UNIX, Linux and Windows servers can be monitored remotely, and the same applies to other systems and applications like VMware, IBM Domino, IBM WebSphere DataPower and SAP.
In addition, the ITM agent builder allows the development of custom monitoring solutions, again agent-based and agentless. For the agentless solution, several protocols are available (WMI, SNMP, JDBC, JMX, CIM, SOAP, HTTP, ICMP).
Choices also exist in provisioning functionality and lifecycle management. Software can be deployed and commands can be executed either using agent-based or agentless management, typically using Secure Shell (SSH).
Finally, these choices also apply in the area of workload management. In addition to an agent-based approach in its fault-tolerant agent, IBM Tivoli Workload Scheduler also supports agentless scheduling using SSH, providing a very lightweight software footprint. No symphony files, events or Tivoli Workload Scheduler messages are transmitted to the target system, so it requires less bandwidth.
A frequently stated issue with the agent-based approach is the lifecycle of agents. In IBM we have a great deal of experience with agent management, and we have clients that have hundreds of thousands of agents under management. In addition, we make use of the IBM Endpoint Manager technology to deploy and maintain agents. So-called fixlets are provided for several agent-based products to ease the lifecycle aspects. IBM is planning to make this function available on our software as a service (SaaS) platform IBM Service Engage to ease the agent lifecycle aspects.
One or the other or both?
As you have seen, there are advantages for both agent-based and agentless approaches to service management. But to me this is not always an either-or question; maybe the combination of both technologies could become the best approach.
For a rapid deployment, you would start with an agentless approach. While this may not provide deep management functions, it would provide quick time to value. You don’t have to negotiate with the various systems owners to get permission to deploy agents, and there’s no need to raise change requests to perform the deployment. You just use interfaces already exposed. Often the provided functionality is good enough.
As a second step, in areas most important to the business, you would then deploy agents for deep, sophisticated management functions.
Both approaches would be integrated into an overall management solution (think of it as a manager of managers) and presented as a hybrid solution to the user.
I hope I have contributed relevant information to the ongoing discussion of agent versus agentless management. Let me know what you think about a hybrid approach, and whether you’ve had any positive experiences with it.