Blog > DevOps > What DevOps Teams Need in an Integration Platform, Part 2: API Developer Experience

What DevOps Teams Need in an Integration Platform, Part 2: API Developer Experience

Integration platforms should abstract away API complexity so developers only need to focus on the intent, not on how to do it

This is a 3-part blog series exploring what DevOps teams need in an integration platform. Download the eBook, Not All Integration Platforms Are Built the Same, to learn more.

In Part 1 of this blog series, we discussed the customization requirements for DevOps teams, including the pros and cons of code, low-code, and no-code customization, as well as how integration platforms should handle versioning and caching. In this post, we'll dig deeper into the API developer experience.

Unlike previous generations of integration platforms, modern platforms must enable deep developer customization to keep up with the new way of managing infrastructure, cloud computing, and the complexity of DevOps processes. In contrast to industries like human resources in which tasks are often repetitive, DevOps processes are much more unpredictable.

Managing cloud infrastructure will inherently look different for every organization, and platforms need to be able to mold to each architecture. DevOps teams also use an array of custom tools, and developer customization will be required to integrate their full toolchain. Under the hood of any great solution should sit a powerful developer platform that can abstract away API complexity. This will enable teams to focus on what they’re trying to accomplish rather than the details of how to interact with the API. The goal is to allow users to define the data they want without having to think about the intricacies of how that data is received. In other words, developers should only have to focus on the intent, not on how to do it.

Identity#

Modern operations teams need access to dozens of systems and tools to respond to an incident, execute a change, or investigate a problem. Limiting access to these systems could inhibit an on-call engineer’s ability to restore a service or roll back a change. At the same time, teams need to ensure there is an audit trail of human data and activity to ensure compliance.

An integration platform that enables teams to pull in data from disparate sources while respecting the identity and permissions of the human viewing that data can help solve this problem. When automation runs on behalf of specific humans, it preserves the fidelity of information in the integration platform regardless of who pulled in the data from what source. This allows teams to continue to manage and respect access to that data outside of its source.

An important part of this equation is the granularity of identity across integrations. Platforms that only enable team authentication for integrations can be problematic. If an integration is connected through a team login, teams lose the visibility and audit trail of which individual took action. The ideal solution is a platform that enables teams to use the same integration while identifying who specifically is taking action.

An integration platform should provide a full audit trail of the data that has been retrieved, when it was accessed, and by whom. These pieces of information are critical not only for compliance but also to ensure teams can evaluate processes and maintain a continuous feedback loop.

Authentication and authorization#

While identification is the act of identifying a person’s identity, authentication and authorization handle how the system proves the identity and specifies access rights and privileges. Managed authentication and authorization provide the freedom to connect to any API without the burden of hard-coding authentication and authorization logic into the integration.

There are three aspects to authentication to evaluate in an integration platform:

  • Developer-provided authentication (API keys) which authenticate any data connections requiring developer permission and stores and updates developer authenticated connections.
  • User-provided authentication which enables single sign-on for users to the integrated system or provides customized connect pages that allow users to authenticate their own data connections.
  • User management which creates a list of user records mapping user accounts to their data connections.

By having all these aspects of identity managed by an integration platform, teams no longer have the headache of handling them within custom glue code, and they can take advantage of having them managed in one place. Instead of writing out instructions for an on-call engineer describing how to access systems, teams can codify them directly within an integration platform where authentication is handled.

Serverless, managed solution#

Serverless integration platforms enable teams to run operations without having to worry about managing and operating the platform on their own servers. DevOps teams should be able to focus on building their own product, infrastructure, and services without having to manage the infrastructure that supports their integration platform.

There are two parts to this equation. First, the whole solution should be offered as Software-as-a-Service (SaaS). Secondly, any code-based customizations in a developer platform should run in a serverless runtime environment. Both of these elements mean the users of the platform are not responsible for managing the service or the code.

Pagination#

API queries to a service could potentially return millions of results, which could put a strain on an API. Pagination, therefore, helps to limit the number of results to help keep network traffic in check. A dynamic API client can handle pagination and automatically request more pages from the API as needed. This allows the developer to decide how many items they need without knowing how the pagination works in each API.

Caching#

Lastly, teams should invest in an integration platform that makes it easier for developers to integrate APIs without worrying about the mechanics of calling different APIs with different mechanisms like caching. A dynamic API client can make 11 caching and rate-limit handling trivial, protecting downstream dependencies that could otherwise become overwhelmed with API calls.

Abstracting away API complexity with DevOps process orchestration#

Unlike previous generations of integration platforms, DevOps process orchestration platforms like Transposit help manage and handle the complexity of APIs so that users only need to focus on the intent, not the mechanisms of how to handle custom APIs. These platforms manage and seamlessly handle identity, authentication, pagination, and caching. Using open and standards-based methods, these platforms simplify the work of creating connectors and integrating new tools and services, whether they are off-the-shelf or built in-house.

Additionally, DevOps process orchestration captures both the human and machine data from incidents, changes, or any other operational process. Often neglected in many integration platforms, the ability to capture human data along with machine data ensures teams have the full context of how processes were carried out while providing an audit trail.

DevOps is all about moving fast with agility. Still, that can’t be at the expense of governance, security, and compliance. DevOps process orchestration platforms help bridge the divide between development and operations teams, providing the operational visibility and workflow guardrails that enable teams to stay flexible and agile while ensuring governance.

Get the eBook: Not All Integration Platforms Are Built the Same

Download eBook

< Back to the blog