In this chapter, we look at what we can do with an on-premises agent, what an agent is capable of doing, and how to deploy an agent. But before we do that, we need to understand the following three topics:
- Why and when an agent can help us
- The different types of agent that ICS offers
- How to get the agent deployed
All our examples so far have illustrated cloud-to-cloud integration or integrations within a single cloud. Whilst this is the likely future of a great deal of IT operations, this is not where things are today when a mix of cloud and on-premises integration exists, and maybe will have to exist this way for a very long time to come; possibly forever. This means that, for ICS to be effective, we need to support accessing on-premises systems and potentially even executing some processing remotely in the on-premises environment.
Once we have understood when an agent is best suited to help us for reasons beyond the simple practicalities, for example, where not all IT systems have been moved into cloud environments, we will work through a scenario. In our scenario, we will have an agent deployed in an on-premises context. This does mean we have some pre-requisites to address. But we will look at those once we understand the agent and deployment options.
With the background completed and having deployed the connection agent, we will create a simple integration taking on-premises data from a database and sending it to Mockable, as shown in the following diagram:
ICS offers two types of agents, namely:
- Connection Agent: Provides a means to connect to systems and data stores that are on-premises or in networks that need to be treated as if on-premises.
- Execution Agent: Sometimes referred to as ICS on-premises or, occasionally, runtime agent. To perform the integration processes in a suitable location other than on the cloud server, for example, when the process starts on-premises and finishes on-premises, do we want to take the data to the cloud?
These agents have different capabilities and environment demands, although there are some basic needs, as you will see as we look through the details.
The essence of the two agents are to provide connectivity to systems running on-premises (or even another cloud) in the case of a connection agent, and to perform the act of executing integration processes on-premises (or someone else's cloud) for the execution agent.
In all of this, there is a downside to the agent model. One of the key benefits of iPaaS and SaaS cloud solutions is that the effort in patching and updating software is in the hands of the service provider. However, the patching and so on of the agents remains in our hands. What is more significant is that the compatibility between server and agent may be a lot more restricted, meaning that we are forced to patch/update agents far more frequently.
Whilst the installation process has some commonality for the two types of agent, including some of the information that needs to be supplied, the actual installation process is different once all the prerequisites are in place. Therefore, the agent installation process will be described for each type of agent when we get to the install stage.