IPaaS vs. API management: Why the enterprise needs both

There are a lot of choices to make in enterprise IT, and often there is more than one best choice. That's the case for iPaaS vs. API management. These technologies are often at odds with each other but are better used together. The arguments as to which one is best, all miss a critical question about workflows, which we'll discuss below.

How and why to use iPaaS

The term platform as a service describes a set of software tools offered to standardize some aspects of cloud hosting and operation. IPaaS is a subset of that: a cloud software framework or toolkit used to integrate applications. IPaaS improves application reliability and reduces overall operations effort. It can also reduce errors.

What makes up an iPaaS, however, is far from standard. Is iPaaS a tool that runs in the cloud, but creates and manages integration components that aren't cloud resident? Does iPaaS integration take place in the cloud instead? Some iPaaS proponents include only integration software, including database and workflows, and others also include development, deployment tools, and in effect, everything. The only commonality is that iPaaS is a cloud service.

How API management works

API management is the set of tasks and tools used to create and optimize the use of software components whose functionality is exposed via published APIs. With API management, you can manage and reuse components and data assets. APIs, then, represent a broad class of assets, and in that sense API management is also potentially broad in scope. API management is a universal strategy because you can do it anywhere you locate your APIs without diverting workflows.

Differences between iPaaS and API management

IPaaS is a cloud framework that integrates the databases and other resources (which can include APIs) for applications that deploy within the cloud, or that connect in a simple way to the cloud. Development to an iPaaS platform simplifies integration where it can be applied. API management is about creating and using the shareable components of software. The two concepts have become competitive only because of "feature creep" in iPaaS.

No one suggests that API management should displace iPaaS -- in fact, the opposite is true. Broader definitions of iPaaS can include API management, or integrate and manage the resources that APIs represent in a different way. IPaaS is a relatively new concept, and as such it gets a lot of attention as well as suggestions that it is the solution of the future. IPaaS is the right choice for many users, but not at the expense of API management.

Why an enterprise needs both iPaaS and API management

Most arguments that frame this discussion as "iPaaS vs. API management" ignore the most fundamental point about iPaaS. Workflows are rarely mentioned in iPaaS debates except as something that integration as a service might target. The problem is that iPaaS must see the workflows to integrate applications and database access. It's difficult to integrate something you don't see.

Moreover, if a workflow doesn't already involve the cloud, using iPaaS to integrate the workflow will create a "border crossing" for traffic. Most public cloud providers charge for traffic ingress/egress, so adopting iPaaS with no consideration for such additional border crossings could significantly increase cloud costs. This also could potentially impact application quality of experience, because diverting workflows in and out of the cloud to integrate them adds latency. This border-crossing issue doesn't create a technical barrier to complete iPaaS reliance, but likely creates a financial barrier to broadening its scope to include all application resources. There is no such barrier with API management.

Applications that dodge this border-crossing problem live entirely within the cloud or have a few simple workflows into and out of the cloud. Most enterprise applications will follow the hybrid cloud deployment model in which iPaaS services run within the same cloud as the application front ends. This likely will not require additional border crossings. Furthermore, multi-cloud use of iPaaS safely avoids the border-crossing issue as long as you identify an "integration cloud" for iPaaS. If you establish a place where all workflows already pass and you integrate there, there is no cost or performance penalty. Don't divert workflows just for the sake of integration.

Even where there's no solid financial barrier to total iPaaS reliance, certain software technology issues may encourage a business to use both iPaaS and APIs rather than choose between the two. A good API management strategy covers the entire API lifecycle, and presents a consistent development framework that involves all software development and operations. Such inclusiveness inspires many companies to expand their iPaaS strategies to include more of the software lifecycle and generate what some call "cloud-centric" development. That expansion likely will increase the number of border-crossing integration workflows, and thus the risk of major cloud cost increases.

IPaaS provides lots of value for companies that prioritize user experience and employ rapid development techniques in their front-end cloud elements. IPaaS also has value to integrate the pieces of cloud workflow that cross over into the data center. These reasons are more than enough to justify taking a look at iPaaS.

API management, even though some consider it old hat compared to iPaaS, is valuable everywhere a business uses or generates APIs, locally or in the cloud. The idea to replace API management with iPaaS is not even a close call. You absolutely need API management -- and you'll need it more as you increasingly componentize your applications. Complement it with some iPaaS where it makes sense, but focus on APIs as your organization's most valuable assets.