除了利用云集成和本地集成以外，利用集成平台即服务（iPaaS）来监督治理在某些圈内也非常流行。尽管iPaaS仍多少处于萌芽状态，但已经被认为是软件即服务集成的主要方法之一，也许距离“步入自己的集成”也不远了。

然而，有些专家，像Ovum的资深分析师Saurabh Sharma却说，iPaaS甚至连成为应用集成的转向方法都还很远。而其他专家则说，随着云的不断成熟，该平台会得到大力推进。

在本问答录中，云代理Appirio的CEO Glenn Weinstein讨论了iPaaS如何在最近几年取得了进展，以及架构师采用这种技术时可能面临的障碍有哪些。

这几年iPaaS是如何演变的？

Glenn Weinstein：7年前，当我们第一次开始实施Saleforce时，它们主要还是独立的实施。通常是直接将遗留的CRM系统用基于云的CRM系统换掉。相当迅速—要我说在过去5年之内实施的那些项目，如果不是多数的话也有相当一部分比例，牵涉到了将云系统集成到更大的企业应用版图当中，包括我们的战略工作在内。

任何时候我们都有超过350个项目在进行，这些项目并不涉及与后端系统、后端数据库、面向客户的门户、数据服务、数据仓库的高度集成。这已经成为了在企业中部署云的真正具有挑战性的部分。大体上来说，应用从一个个功能来看都能照顾好自己。将应用的功能用另一个交换是一个相当直接的活动。

供应商真的已经成熟了。可以看到，像Informatics那样的公司开始真正优先推进基于云的集成解决方案而非本地解决方案。集成领域出现了Cast Iron和Boomi 那样的非常正统的企业级集成平台，以及大量的中间层供应商。我的工作流一般是从安装服务器开始,然后安装Oracle数据库，再让它成为本地解决方案的一部分。现在任何一个项目都不是那样进行了。我们频繁地与客户协作来实施的不仅包括应用，也包括在一个完全公有云环境下的集成骨干。

实施iPaaS时架构师面临哪些障碍？如何才能克服这些挑战？

Weinstein：在实施iPaaS时，架构师需要注意的最重要的一件事是模型的伸缩性，既包括单个事务的规模，也包括每小时事务的整体节奏。这两种情况下你都需要小心，别对你的iPaaS能处理什么做出不正确的假设。你必须对iPaaS平台具备一定的知识和经验以便发挥它的最大效应。

事实上基于云的集成平台是位于防火墙之外的，需要在客户安全阶段预先进行早期规划。对于某些公司来说，可以采取与以往不同的模式。在iPaaS的情况下，你一般都会有从防火墙内部发起事务。毫无疑问，你希望安全团队在早期加进来参与你的提案设计，以免后面出现不好的惊喜。

这个话题我不想延伸得太多，但是事先跟提供本地平台和基于云的平台的供应商讲清楚，你打算用哪个平台也是很重要的。人们有时候会把自己产品的哪些功能是部署在本地，哪些部署在云端给搞混了。你必须事先指明自己的意图。

iPaaS是不是现在企业架构师用得最多的集成方法？

Weinstein：我们自己选的话Appirio也许有点算得上是一个，因为显然我们正在跟喜欢公有云或至少对围绕着公有云部署战略感兴趣的企业合作。不过哪怕在我们的客户群当中，我也还不能确定是否能称之为主流。我只能说我们的客户当中有相当一部分的人感兴趣，并朝基于云集成平台的这个方向前进。也就是说，即便在我们的客户群中，我们看到的往往还是以本地集成主干居多。

本着循序渐进的精神，一种相当典型的做法是实施基于云的应用，然后将其与现有的集成主干再进行集成。如果没有其他办法，则将在集成主干流转的当前业务流程替换掉。然后，寻找新的机会去开发新的集成，开辟新的价值领域，或者实施我们也许尚未知道的新的业务流程，再试着将这些放到基于云的集成平台上。

我认为我们尚处在数量显著的公司彻底向集成即服务迁移的早期。的确，你可以在较小规模的公司里看到这个趋势，Appirio就是一个例子；我们是100%在云端的，包括我们整个企业基础设施在内。

iPaaS的未来如何？

Weinstein：我认为我们将看到iPaaS的流行度迅速增长。集成开发者希望在快速演进的现代平台上工作。我认为你将看到的不仅是供应商向iPaaS迁移，集成开放社区也会推动这股势头。我还认为你会看到更多的供应商，尤其是SaaS供应商接受越来越健壮的Web服务API。尤其是那些可处理更大规模批数据的场景。这使得它们成为iPaaS友好型供应商，对于你未来的API来说，这将会是一个越来越重要的条件。对于所有供应商来说都一样，不仅仅是SaaS供应商。