If you're thinking about using an Application Release Automation tool, like IBM UrbanCode, one of the things to consider during your evaluation of the solutions available is how you want to, or don't want to, use agents. While you're thinking about this, you'll want have three key aspects of your implementation uppermost in your mind:
The IBM UrbanCode architecture is designed in multiple parts:
A common challenge with multiple data-centers is that firewalls exist between data centers or network segments. Enabling server-agent communication requires either broad firewall exceptions or many exceptions. The Agent Relay helps alleviate these challenges by consolidating Agent traffic. Relays may be installed in groups to provide high availability.
If you choose not to use agents, you'll need to use some sort of service to communicate with your deployment targets - in the world of Linux this is usually SSH (Secure SHell) and in the Windows world, WinRM (Windows Remote Management). Both of these services open up a port and listen for incoming connections.
The process initiation and stream handling is done on the server and there may be a limit to the volume of concurrent processes the server can handle at any one point in time. Also, if the central deployment server suffers an outage during a deployment, an agentless system will know a command started, but will not know the status. Generally, all deployments that were running at the start of the outage will be considered to have failed with the results of the most recent commands unknown.
You may already have SSH or WinRM running, in which case your setup overheads will be nice and low. If not, you'll need to visit each target and enable and configure the connection services.
Agent Based Deploys
In this scenario, an agent is deployed on the target environment where it runs a process. The agent based process does not listen for incoming connections - the process itself initiates a connection with the server. This means that any security implications around having a port listening are moved to the deployment server rather than being on the target application itself. This makes this approach much more secure; you still have the benefit of SSL encryted traffic and mutual end-point authentication as with agentless SSH based deploys but you don't listen for incoming connections - there aren't open ports on the application servers.
With an agent based setup, the process initiation and stream handling is handled at the agent, markedly improving scalability and mitigating risk when network fidelity or performance is compromised. With agents, because each step is ordered as a unit and the work is done by the agent, an outage of the central deployment server has no impact until the step is complete. If the server is down, the agent waits for it to come back, reports the results, passes back the logs, and accepts the next command. If the central servers are configured in a multi-master high availability configuration, the agent is directed to a different master and reports the results.
With UrbanCode, if you already have SSH/WinRM set up, you can use this to deploy your agents swiftly and easily. If not, you'll still need to visit every end-point to do this or install and configure your agents - there isn't much difference between these two approaches.
Alternately, if you have a different automation agent already installed to manage your server infrastructure, the installer is designed to be run headless through automation. UrbanCode also has a Puppet module and a script package for PureSystems and SmartCloud Orchestrator.
Some organisations we talk with raise concern about potential performance impacts on their applications but the UrbanCode developers architected, design and built their agents to be minimally invasive. They only consume a minute amount of memory and virtually no processor power when active and the impact of an idle agent is close to zero. A working agent will consume a tiny amount of resources as it performs the deployment - a small price to pay for the increases in volume, frequency and consistency of releases an ARA tool brings.
Some of our customers' policies/preferences are averse to having agents on the production services, but the increased security, scalability and robustness of an agent based architecture appeals. Installing an agent on an intermediate box, an agent relay (or proxy, broker or worker agents) may be the best solution.
- Deployments require some means of acting on a target server, either through listening execution services such as SSH, or an agent
- The agent based approach is often preferred because it is more secure, scalable and robust and has very little additional setup overhead
- A system with agents can behave similarly to an agentless tool by using proxy agents. Using several agents boosts capacity by spreading load
- Agent based deployment tools like IBM UrbanCode Deploy can act like agentless systems but an agentless system cannot act like an agent-based tool
- IBM UrbanCode's architecture is designed to scale to meet enterprise requirements: high availability, horizontal scalability, quick response and tight security