Release Automation: Agent v. Agentless
Many enterprise software systems can be categorized as either “Agent-based” or “Agent-less”. This blog is going to discuss why any organization would choose to select one method over the other, specifically around Release Automation and Software Deployments.
The first question one should pose – regardless of whether the potential solution is agent-less or not – is this, “What tasks am l looking to conduct as part of my Software Deployment solution?” At this point I also want to make it clear that when l am referring to “Software Deployments”, l am addressing the deployment of software across the end-to-end software development life cycle, not just production systems.
Without creating an exhaustive list that anticipates every granular task, required by every organization, for every software deployment scenario, I shall attempt to summarize the most common and typical steps and tasks:
- Send artifacts to a remote server.
- Manage and manipulate artifacts on a remote server.
- Execute remote ‘jobs’ on a remote server – this can be categorized further as:
- Execute a remote script that already resides on a remote server,
- Send a script to the remote server and execute, and
- Execute a system command on the remote server.
- Compile source code on remote server.
- Start / Stop Services on remote server.
- Capture the results and output of a remote script or system command.
All things considered, the mechanisms employed around deploying software to remote servers is finite. Now that we understand what we need to manage a software deployment, we now need to assess the merits of whether or not to use an agent-based system.
To be blatantly clear, I would like to state now that my preference is firmly on the side of agent-less. This opinion is formed through many years of working with enterprise software – not just in the Release Automation space – and witnessing real-world limitations and challenges.
Disadvantages of an Agent-based Release Automation Solution
Agents are a great way of building robust connectivity between the deployment server and its end points – the remote servers to which one would like to deploy software and systems. However, any agent-less system could be deemed as robust if it is based on SSH/SSL secured connections.
In my opinion, the overheads associated with an agent-based solution far outweigh those of an agent-less solution.
Agent Installation
Obvious, but crucial, an agent-based solution will require the customer to install agent software on each and every end point to which the customer is looking to deploy software and systems. In small companies this may not be a significant problem, but when dealing with large enterprises that might have hundreds, if not thousands, of end points then the resource requirements increase substantially.
Agent Configuration
Each and every agent will require configuration settings amended to ensure it can connect to the solution server. Each agent may also require configuration settings altered based on the role of the agent.
Agent Maintenance
Software vendors continually update and improve their solutions; an agent-based solution will, therefore, potentially require software updates. Again, not such a huge problem for small companies but large organizations will have to allocate resources for these upgrades, possibly initiating dedicated project teams to complete the upgrade effort.
Firewall & Relay Configuration
Agent-based systems will undoubtedly require firewall configuration changes to allow the agents and solution server to communicate and relay instructions and data between numerous domains within large corporate networks.
Agent Availability
Installing an agent will typically involve installing the agent software as a service running on the remote server. As with any service, it is possible that this service may ‘fail’, require configuration changes, need recycling, not be compatible with other services or, as a worst case scenario, require a complete re-installation.
Platform Support
Agents are a piece of software built for a specific platform; if you want to deploy to Windows then you will need a Windows agent, UNIX will require its specific agent, so too will Linux, and so on. Since it requires development resource for any vendor to build a specific agent, it is most cost effective for vendors to target the distributed platforms – Windows, UNIX and Linux.
However, large organizations make use of various platforms designed to address specific needs. Financial Services companies will make use of fault tolerant and high transaction processing platforms such as; iSeries, Stratus, OpenVMS and Tandem. Another example is Retail organizations that are likely to make use of the IBM4690 platform, for example. It is highly likely that these platforms are not supported by agent-based systems and prevent, therefore, organizations from achieving full Release Automation.
Advantages of an Agent-less Release Automation Solution
Release Engineer (from OpenMake Software) is an agent-less solution. This means that all of the above agent-based disadvantages are addressed by removing the need for agents.
- Agent Installation – Not Required
- Agent Configuration – Not Applicable
- Agent Maintenance – Not Applicable
- Firewall & Relay Configuration – Most organizations will likely use SSH/SSL to connect and administer their server infrastructure, and since Release Engineer utilises the same protocol then no firewall changes will be necessary. Even if firewall changes are required, it’s no more effort than the agent-based solution and the connectivity configuration will be robust and secure.
- Agent Availability – There is no reliance on the availability of any agents.
- Platform Support – Since Release Engineer utilises standard protocols then the extent of the platforms to which Release Engineer can deploy is diverse, such as; Windows, UNIX, Linux, iSeries, OpenVMS, Tandem, Stratus, IBM4690, Tru64…
