Managing Servers: With Agents and Without

Managing one server—easy. Managing a data center full of servers—difficult. Managing a hefty combination of physical on-premises servers and virtual servers in the cloud—migraine-inducing. The good news is that there are many automation tools for managing those servers. The bad news is that it’s not only a challenge to find the right set of tools and products, but it’s difficult to know where to begin.

Let’s look at the problem and then the challenges and advantages of two specific approaches to automating server management: agentless and agent-based automation.

The Scene: 50,000 Feet
Servers. Some running Windows. Some running Unix. Lots of versions, lots of flavors. Perhaps your data center is homogenous. Perhaps it’s a broad mix of server platforms, each chosen for good reason at a specific point in time for a particular application.

If you only had a handful of servers, you’d connect a keyboard and monitor and run management tasks manually, like checking memory and disk utilization, killing rogue processes, running cleanup routines, analyzing log files, flushing caches, installing patches, and deploying applications. With remote login, you can manage each server directly from the office, from home, or even from Starbucks using your iPad.

At some point, you (and your hard-working admins) will hit a wall, and will need to turn to automation. While remote login to a specific server, followed by manual intervention, may be necessary when something goes awry, it gets old (and expensive) very quickly. From provisioning to monitoring, from boosting performance to installing new software on a server cluster, automation is the way to go.

If you are dealing with dozens or hundreds or thousands of real and virtual servers, automation is the only way to go.

To Agent or Not to Agent?
The remote automation world can be broadly split into two types of solutions based on how they connect to these target systems: agent-based and agentless.

Agent-based automation refers to when a small piece of software—called an agent, service, or daemon—is installed on each target server. The management automation software communicates with that agent, which in turn performs the necessary administrative tasks on that server.

In agentless automation, instead of installing and using its own agent, the management automation software interacts with remote-control functionality built into each host-operating system to perform the administrative tasks.

Both of these approaches have benefits and weaknesses. Let’s look at the pros and cons of each.

With agent-based automation solutions, a potential benefit is that the agent is often designed by the same company that supplies the automation server and its administrative console. This provides a “one-stop shop;” you get all the support from one source. Another benefit in some environments, particularly those that are heterogeneous, is that the agent is consistent across platforms. Whether it’s Windows, Linux, or Unix, the management platform talks to ”the same” agent on every server. The consistent set of APIs and services makes it easier to develop server automation tools that work across those platforms.

A downside, however, is that someone has to install those agents on all the remote servers. That’s a management task, of course. It’s not an insurmountable one, but it does mean that you can’t use most of the out-of-the-box server images. You’ll need to create your own that contain the agent or agents configured for your management program(s).

By contrast, with an agentless solution, you can leverage out-of-the-box server images and don’t need to build images or installation templates specifically for your automation software. Instead, you can rely upon the native remote administration interface built into each of those operating systems and versions. WinRM is the most common for Windows these days, and SSH is essentially universal for Unix and Linux.

Let’s Talk Maintenance and Trust
Microsoft maintains WinRM. Your favorite Linux and Unix distribution provides SSH (Secure Shell). If there are bugs, flaws, or updates, your operating system patch process will take care of updates to those platforms. We know that flaws in SSH and WinRM will not only be quickly discovered and published, they will also be rapidly fixed.

In an agent-based situation, maintenance of that agent is handled by a third party—one that is not necessarily motivated to disclose and fix security flaws. It’s not on the same timeline as operating system patches. Indeed, maintaining the agent is another task that you may have to automate.

Not only do you have to maintain the agent, but you have to trust it. In order to do its job, your management automation system often has to have administrative privileges on target servers.

SSH has been around since 1995, and it’s had a lot of development and scrutiny from very smart people to make sure it’s secure, it does all the right things, and so on. Microsoft’s WinRM is an implementation of the WS-Management protocol; it’s much younger than SSH, but is still a mature application built on open standards—and with gazillions of installations.

Third-party agents often run with total administrative or root access, all the time. Have they had the same level of scrutiny, of security engineering, and of liability engineering that SSH and WinRM have had? I think it’s fair to say that one often simply doesn’t know, especially for proprietary offerings.

Stick with Standard Tooling
The more you can stick with standardized interfaces like SSH or WinRM, the greater the chance of you being able to use other off-the-shelf tools and technologies. And, of course, the more likely you can leverage expertise that’s quite common, because SSH has been around for a long time, and because WinRM is a Microsoft technology that’s being taught to nearly every Windows-certified systems administrator.

Because the agentless interfaces in Windows, Linux, and Unix are open to every compatible management automation tool, you can choose your specific tools for legitimate business or technical reasons without having to install special agents for each tool. You do not need to do anything special to your virtual and real servers to enable automation tools to work. 

By contrast, if you have to use a variety of different agent-based automation tools, you might need to install (and maintain) multiple agents on each machine. Each agent will consume memory, take up a port, and if they “phone home” to the automation server system, will cause network traffic. (Of course, that’s a benefit of agent-based automation systems—they can call home. SSH and WinRM are passive interfaces.) Once you start multiplying this by dozens or hundreds of real or virtual machines, agents represent significant overhead and background noise that you're creating in your systems.

To summarize, as servers scale and reach beyond the local office into remote data centers and the cloud, automated management solutions aren’t a luxury. They are a necessity. Those automated management systems need to reach into your servers to monitor them, push out software installations, and more.

When you look at the automated management solutions available today, you can choose those that use native operating system management access points—namely SSH and WinRM—or you can look at those that install solution-specific agents.

In some scenarios, agents make sense, such as when you need call-home capabilities or when the remote servers aren’t always connected to the network or aren’t always reachable by the automation server. In those cases, the increased intelligence in the agents, and their ability to work autonomously, can make them the more suitable choice.

In most server management situations, however, agentless systems using SSH and WinRM are cleaner, safer, more standardized, and preferable in terms of maintenance and utilization of system resources. You should ask yourself: “Should you have a specific scenario where you need the added complexity, overhead, and risks of a third-party automation agent? Or should you use the known-and-trusted native SSH and WinRM capabilities built into your servers—without the hassle and the migraine of third-party agents?”