Why the business needs both
There are many choices to be made in enterprise IT, and often there is more than one. better choice. This is the case for iPaaS vs. API. These technologies are often at odds with each other but are best used together. The arguments for which one is better 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 available to standardize certain aspects of hosting and operating the cloud. IPaaS is a subset of that: a cloud software framework or a toolkit used to integrate applications. IPaaS improves the reliability of applications and reduces the overall effort of operations. It can also reduce errors.
What constitutes an iPaaS, however, is far from standard. Is iPaaS a tool that runs in the cloud, but create and manage integration components that don’t reside in the cloud? Does iPaaS integration take place in the cloud instead? Some iPaaS proponents only include integration software, including a database and workflows, and others include development, deployment, and, in fact, everything as well. The only thing in common 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 through published APIs. With API management, you can manage and reuse components and data assets. APIs therefore represent a broad asset class and, in this sense, API management also has a potentially broad scope. API management is a universal strategy because you can do it anywhere you locate your APIs without hijacking workflows.
Differences between iPaaS and API management
IPaaS is a cloud framework that integrates databases and other resources (which may include APIs) for applications that deploy in the cloud, or that easily connect to the cloud. Development to an iPaaS platform simplifies integration where it can be applied. Managing APIs involves creating and using the shareable components of the software. The two concepts only became competitive because of the “feature creep” in iPaaS.
No one is suggesting that API management should replace iPaaS – in fact, the opposite is true. Broader definitions of iPaaS may include managing APIs, or integrating and managing the resources that APIs represent in a different way. IPaaS is a relatively new concept, and as such, it is receiving 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 a business needs both iPaaS and API management
Most of the arguments that frame this discussion as “iPaaS vs. API management” ignore the most basic point about iPaaS. Workflows are rarely mentioned in discussions about iPaaS, except as something that Integration as a Service might target. The problem is that iPaaS needs to see workflows to integrate applications and database access. It is difficult to integrate something that you cannot see.
Additionally, if a workflow does not already involve the cloud, using iPaaS to integrate the workflow will create a “border crossing” for the traffic. Most public cloud providers charge for entry / exit of traffic, so adopting iPaaS without considering these additional border crossings could dramatically increase cloud costs. It could also impact the quality of application experience, as diverting workflows in and out of the cloud to onboard adds latency. This border crossing issue does not create a technical barrier to fully relying on iPaaS, but likely creates a financial barrier to expanding its scope to include all application resources. There is no such barrier with managing APIs.
Applications that avoid this border crossing problem either live entirely in the cloud or have a few simple workflows in and out of the cloud. Most enterprise applications will follow the hybrid cloud deployment model where iPaaS services run in the same cloud as the application front-ends. It probably won’t require additional border crossings. In addition, the multi-cloud use of iPaaS safely avoids the problem of crossing borders as long as you identify an “integration cloud” for iPaaS. If you establish a place where all the workflows are already going through and fit in there, there are no cost or performance penalties. Don’t hijack workflows just for the sake of integration.
Even when there isn’t a solid financial barrier to completely relying on iPaaS, there are some software technology issues that can cause a business to use both iPaaS and APIs rather than choosing between the two. . A good API management strategy covers the entire API lifecycle and presents a cohesive development framework that involves all software development and operations. Such inclusion prompts many companies to extend their iPaaS strategies to further include the software lifecycle and generate what some call “cloud-centric” development. This expansion will likely increase the number of cross-border integration workflows, and therefore the risk of significant increases in cloud costs.
IPaaS offers great value to companies that prioritize user experience and use rapid development techniques in their front-end cloud elements. IPaaS also has value in integrating elements of the cloud workflow that intersect in the data center. These reasons are more than enough to justify taking a look at iPaaS.
API management, although some see it as an old hat to iPaaS, is valuable wherever a business uses or builds APIs, locally or in the cloud. The idea of replacing API management with iPaaS is no small feat. You absolutely need API management, and you’ll need it even more as you integrate your applications more and more. Supplement it with some iPaaS where it makes sense, but focus on APIs as your organization’s most valuable assets.