Data integration solutions come in one of three categories. First there’s old school data integration solutions created in the 1990s from the EAI movement, now expanded to include public cloud computing domains. Second, newer cloud-based iPaaS (integration platforms as a service) solutions built from the ground up as on-demand integration servers hosted on the open Internet, but existing outside of public cloud providers. Third, data integration solution existing within public clouds, which are typically more primitive. However, these native services are easily deployable from inside a public cloud provider.
Which one to use when?
The old school data integration solution is typically not desirable for cloud computing, considering that cloud-based integration is often an afterthought. That said, many of these solutions are already installed and are very difficult to unseat without a tremendous amount of cost and risk.
My general advice is to leave them where they are, as long as they work up to expectations. Although they may not be desirable for integration with public cloud-based applications and data stores, due to their on-premises enterprise focus, replacing them with iPaaS or cloud-native data integration solutions is cost ineffective.
iPaaS solutions have been built with data integration in the public cloud in mind, but can also handle on-premises and traditional data integration. These have come into the market in the last 10 years and are purpose-built for hybrid and multicloud problem domains that include internal systems as well.
For the most part this is the sweet spot for data integration, cloud or not. The on-demand approach means that you likely don’t have to deal with hardware and software configurations, the software is updated automatically and continuously improved, and the connectors and adaptors are purpose-built for cloud-based systems and databases.
Cloud-native integration solutions usually focus on specific patterns, such as integrating data streams and raw messaging. Although there are connectors and adaptors for most native systems that produce and consume data, integration with on-premises systems or other public cloud providers is typically not supported without a great deal of custom development.
All three types of solutions have their purpose. Leave old school data integration in place unless there is a compelling reason to remove it. Keep in mind that it can act as an on-premises data access gateway for the iPaaS tech as well. You can expect to replace it at some point, but pushing it five years down the road means that better solutions will be available.
Cloud-native data integration largely focuses on tactical solutions that are much more primitive in nature. They do provide tools for intracloud integration, but for larger strategic integration platforms or general purpose data integration, they fall short by design.
That leaves iPaaS as the data integration tool of choice for most cases. The technology is mature and works to expectations. Enough said.