Any time a componentized application is deployed, its components must be able to find each
other, connect with storage resources and, ultimately, connect with the end user. If the
application's resource commitments are static, then the application's components have static
addresses and can be integrated at the time of deployment. Some of this is done manually; some
occurs through the use of provisioning and integration tools.
In the age of cloud, it's only logical that integration itself would become a cloud service. And that service -- Integrated Platform as a Service or iPaaS -- is not only the best way to integrate cloud applications, it may be the only way.
In short, iPaaS is a type of cloud-hosted application component "wrapper" that surrounds a collection of application components and a set of resources -- connecting the two in a consistent way. iPaaS creates a virtual computer or middleware platform in the cloud that, like any cloud platform, can host applications and support users.
Cloud app integration struggles
Manually integrating cloud applications has two problems. First, the location of resources in a cloud vary depending on how the cloud hosts applications, so just finding the resource to link with it may be difficult. Second, some of the integration tasks -- load balancing and workflow handling via message and service busses, for example -- should actually be considered "cloud applications." Performing these functions in a specific place not only introduces a single point of failure, it can also result in unwanted network delays if the integration elements aren't placed in a location that also suits application components. The obvious solution is to host these integration functions in the cloud with iPaaS.
In the age of cloud, it's only logical that integration itself would become a cloud service.
At its foundation, iPaaS is a set of "connectors." On the "downstream" side, the connectors are linked to application components through a process much like a directory function or a publish-and-subscribe application interface. When a cloud component is loaded onto resources, it can be registered with iPaaS and linked to a connector. This connector presents a published, constant interface (API) to users and other components on the "upstream" side of the connector. Applications can reference these upstream APIs and reach the components regardless of where they are connected.
This process is not unlike the universal description, discovery and integration (UDDI) function of service-oriented architecture (SOA) applications. Were iPaaS limited to this basic form, it might not offer much utility; however, the collection of APIs of a basic iPaaS effectively create a cloud platform similar to PaaS. Management applications can be provided in the iPaaS framework that use cloud and middleware management tools to load applications onto resources and then automatically register them with connectors.
With work, iPaaS means more for the enterprise
Orchestration tools, which encompass message and service busses as well as associated business process execution language (BPEL) tools, can drive workflows by referencing upstream APIs of the connectors. They can also be linked to the application components wherever they are hosted. Adding management and orchestration to the basic iPaaS framework creates enough utility to make the concept interesting for most enterprises, but even more improvement to the iPaaS framework is possible.
iPaaS installations can be integrated with "service connectors," or connectors that represent platform services and not user components. These services include not only management and orchestration functions, but also a full range of middleware features, including Database as a Service (DBaaS), network virtualization and control, as well as custom business functions that could be syndicated across company boundaries to support partner supply-chain processes or customer-to-supplier integration. By properly applying iPaaS, companies could set up partnership-based platforms for integrated applications and even build collaboration-based apps.
Third-party software providers could publish software through iPaaS connectors in an "as-a-service" model or sell software that could be registered with iPaaS for easy integration. If the iPaaS deployment didn't offer native services, like database access, third parties could add these services using connectors, further enhancing the iPaaS application environment and improving its utility and functionality.
iPaas could signal seamless integration in hybrid cloud
The iPaaS framework could allow for seamless integration of resources across multiple clouds and between cloud and legacy applications that use SOA or RESTful Web interfaces in a hybrid cloud model or multi-vendor cloud apps. When an application component is loaded anywhere across the range of available resources -- public or private -- the iPaaS framework would link it to the downstream side of its appropriate connector; users would find the application component using the published and constant upstream-side API.
The iPaaS elements themselves are cloud-hosted and can be replicated or moved if the software provides the facility; this enhances availability and potentially improves performance by allowing users to manage where their iPaaS hosting points are, relative to their cloud resources.
Realizing iPaaS' potential is another matter. There are three sources of iPaaS functionality:
- IT companies, including IBM, HP, Dell, Software AG, SAP and others, have private cloud or Software as a Service (SaaS) tools that could be cloud-hosted to create iPaaS. Some horizontal and vertical industry community cloud hosting of this software is already available.
- Cloud integration tools may themselves be cloud-hosted to create iPaaS; some tool vendors are doing this or plan to enter the space shortly.
- There are a few iPaaS providers who launched the service as their primary offering.
The number of potential iPaaS providers is much larger. Any competent developer organization, even enterprises themselves, could easily visualize how to create an iPaaS offering of their own and develop a basic package. The execution of the full range of credible iPaaS features is a more significant development task, however, and iPaaS is most credible when presented as a cloud service from public cloud infrastructure -- not something a user built or deployed. Software providers could build iPaaS packages and host them on a public cloud, which is the most promising source of iPaaS today.
Slow adoption may hide the true benefits of iPaaS
The largest barrier facing iPaaS is a lack of management understanding of its value. Many companies considering a cloud deployment won't even encounter iPaaS or consider it -- even when it would have clear value to them. Public cloud service providers rarely encourage users to consider iPaaS, and the current number of users of the concept is small enough to limit opportunities for user-to-user dialogues and support communities.
It's hard to see how cloud computing can advance successfully to mission-critical applications that dominate IT spending without something like iPaaS to manage application integration and multi-source resource sharing. iPaaS may not be a common cloud term yet, but it's a critical one.
iPaaS may also be a factor in leading both cloud service providers and cloud consumers toward a PaaS cloud model. Integrating service features into the cloud creates PaaS, even if you start with basic IaaS. If iPaaS succeeds there will surely be a drive to add other service features. At some point, iPaaS may give us the foundation for true cloud-specific applications, and that would be an enormous advance for sellers and cloud adopters.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in March 2013