Adapters vs. Integrations

Overview

Itential’s automation products not only unify network operations across multiple systems, but they also give a tremendous market advantage to accelerate next-generation, agile networks while maintaining existing infrastructure. Itential’s signature platform for NetDevOps, Itential Automation Platform (IAP), offers a low-code solution suite for solving today’s modern network configuration and compliance requirements.

Alongside IAP is the Itential Automation Gateway (IAG), a stand-alone integration to popular network automation tools such as Ansible, Terraform and Nornir. For a standardized way to rapidly connect the various protocols required by application vendors, Itential offers two types of resources: adapters and integrations.

This best practice guide will help you to understand the use cases for adapters and integrations at Itential. We will begin with an articulation of what adapters and integrations are. From there, we will explore the use cases and strengths of each so you can choose the right path and utilize the best of what Itential has to offer for any given situation.

The Evolution of Itential Adapters & Integrations

Adapters in Itential were first developed in 2015, and presently there exists over 200 different kinds of open-source adapters. Their primary purpose is to integrate Itential Automation Platform (IAP) with other network applications and systems.

Through Itential’s evolution, integration models were introduced in December 2020 as a lighter-weight, faster way to integrate external systems. Integration models are better suited for certain use cases where we have OpenAPI 3.0 or Swagger 2.0 available.

Next, let’s explore the specific strengths and differences of adapters versus integrations so that you can choose the right tool for your needs.

Building Adapters & Integrations

Adapters are code-driven. Apart from 200 opensource adapters, if you need to build new adapters, you can use the Adapter Builder. Adapter Builder requires OpenAPI 3.0 or Swagger 2.0 documentation to generate the adapter and the user then places the automatically generated node.js onto the file system. This allows a high degree of customization available to suit the user’s needs.

Integrations are model-driven and simply require understanding of the desired API calls. Since they are lightweight, they are not placed on the file system. To build an integration, first, you’ll upload the OpenAPI 3.0 or Swagger 2.0 document via the UI, and this automatically creates the Integration Model (stored in a MongoDB Collection). There is an option to validate the document before creating the integration.

Deployment

To deploy adapters, you will first need to copy the code into the IAP file system. From there, run npm install and then restart the IAP server to start using the adapter. If there are multiple IAP servers in your infrastructure, then either follow the same steps to upload the adapter code and run the npm install on each IAP server or copy the adapter with npm folder and restart the server. For Itential cloud infrastructure, the opensource adapters are already available.

For integration models, there is no need to restart the IAP server because the deployment is UI-based. A benefit of using the Integrations Model is that in an infrastructure with multiple IAP servers, all the servers sync up automatically upon deployment.

Customization

Adapters can be customized according to the needs of the API calls, whereas integrations cannot be customized. Adapters are flexible enough to add or update the API calls whereas integrations are limited to the specification document.

For example, if the result of an API call is this:

You can customize the adapter call to just return the result as “status.result.data”, but using an integration you have to deal with the entire status.

Memory & CPU (Resources)

Integrations can be multi-process and not file system based. They do not use any system resources when idle, and they use less resources than adapters while in-use given that they are multi-process. Integrations can scale up on demand.

Adapters, on the other hand, are single processes. These are file system based and they hold a PID (Process ID) that uses memory (~130 MB per adapter instance) even when idle. When you run multiple tasks, adapters use more memory and CPU than integration models.

Supported Protocols

Adapters give you more flexibility with SOAP, and they work with the following support protocols: HTTP and gRPC. Integrations, on the other hand, only work with the HTTP (REST, SOAP) protocol.

Authentication

To communicate with external systems, adapters and integrations need to be able to authenticate with the external system.

Adapters can be designed to provide support for a variety of authentication standards, such as Basic, OAuth, Static tokens, and other similar methods that do not require manual intervention. Additionally, adapters can accommodate different endpoints for authentication purposes.

Integrations support API Key (including AWS), HTTP (Basic) and OAuth2 (only for 2023.1). For integrations, the OpenID Connect scheme is not currently supported.

Security

Adapters support SSL whereas Integrations support SSL but only for publicly signed certificates. For self-signed certificates to work with Integrations, the keys need to be manually added to the key store.

Version Control

In terms of version control, whenever a new version of an adapter is available, the adapter needs to be pulled and the node modules reinstalled. After the update, the adapter must be restarted.

For integrations you can have multiple versions and create multiple instances per version. Each instance of an integration is independent, consequently requiring a workflow change in the event of a new integration version being used.

Migration

Integrations are easy to port from one infrastructure to another. For Adapters, one needs to follow the same process as the initial install.

Health Checks

Adapters are equipped with health checks, which do not count as active calls. These health checks can be configured as startup or intermediate. It’s important to note these health check calls are not considered as active status checks for other systems, but rather operate as timed polls. In contrast, Integrations do not have the capability for health check calls, and therefore, their operational state, such as availability or status, cannot be checked unlike adapters.

Logs

Adapters and Integrations both provide multiple levels of logging that includes info, warning, debug, trace, and error. Debug and trace logs are beneficial in troubleshooting, but level should remain warn info in lower environments and error in production.

Use Cases

Adapters are used whenever there is a requirement of external system connections using REST, SOAP, gRPC, or to build a wrapper over libraries like Mongo. Adapters also are used when you need to add custom calls and when there is no restriction of system resources (On-Prem).

Integrations should be used when an OpenAPI 3.0 document is available and there is no need for any customization. When deploying on a Cloud infrastructure, system resources are limited.

Feature Comparison

Adapters and integrations each serve a unique purpose and have different properties that make them suitable for a variety of needs and use cases. For a quick summary of the differences between adapters and integrations, see the table below.