有关集成平台即服务（iPaaS）当前形势的Virtual Panel探讨-InfoQ

主要结论

iPaaS 已经不仅仅是云中发生的集成。iPaaS 可以充分利用动态缩放、容器、资源管理和自助服务等云平台固有的能力。

SaaS 连接器依然适用。如果出于生产力、简化、抽象，以及安全等原因需要直接调用 API，此时 SaaS 连接器是一种首选的做法。

在 ESB 和集成中介（Integration Broker）方面根深蒂固的 SOAP 已经让位于 iPaaS 中的 REST 和 JSON。

iPaaS 的未来在于连接并促进与分析、机器学习，以及大数据有关的其他高价值业务成果。

数字化转型是组织从传统本地中间件迁移至 iPaaS，以降低成本并提高速度的驱动力。

集成平台即服务（iPaaS）已成为连接移动、SaaS、物联网、大数据，以及本地业务线（LOB）系统的主流方式。随着客户将工作负载迁入云中，iPaaS 平台成为了负责执行集成的中心位置。

本次 Virtual Panel 讨论侧重于 iPaaS 目前的发展形势，以及集成式服务这种交付模式未来的发展方向。针对这个目的，InfoQ 邀请了来自 MuleSoft、SnapLogic 以及 Microsoft 的思想领袖参与本次对话。

本次讨论的参与者包括：

Dan Diephouse - MuleSoft产品管理总监，同时他也是 MuleSoft 的 iPaaS 产品：CloudHub 开发团队的一份子。
Darren Cunningham - SnapLogic公司营销副总裁，主要负责产品管理和产品对外营销工作。
Jim Harrer - Microsoft云与企业技术集团资深集团项目经理，他的团队主要负责 BizTalk Server 和 Microsoft 的 iPaaS 产品：Azure Logic Apps 的项目管理工作。

InfoQ 在本次讨论中提出了 8 个不同问题，我们的结论如下：

InfoQ：大部分 SaaS 供应商会通过 RESTful API 与自己的应用程序集成。那么针对具体应用程序的连接器适用程度如何？开发者为何要使用连接器而非供应商提供的 API？你们的客户都在使用哪些流行的连接器？

Dan Diephouse（MuleSoft）：RESTful API 彻底改变了集成这一领域。通过这种 API，任何人不光能用 SaaS 应用，而且可以用任何应用轻松地相互连接并以此为基础构建创新成果。因此 MuleSoft 在这一领域进行了巨大的投入，帮助开发者更容易地设计、查找并使用 RESTful API。为了帮助大家更轻松地记录 RESTful API，我们还加入了 RAML 工作组，对 RAML 规范的普及做出了贡献。最近发布的 1.0 版规范使得以往难以实现的目标变得轻而易举。想试试手工编写 JSON 或 XML 架构吗？不用，谢谢！看看 RAML 数据类型你就会明白我的意思。我们的目标是帮助客户更轻松地着手定义并编录可重用的 API。

定义完成后，即可通过我们的连接产品 Anypoint Exchange 发现 API（这里提供了一些范例）。这种功能直接内建在我们的 IDE：Anypoint Studio 中，开发者可以在一个位置浏览一整套井然有序的 API。我们还使用 RAML 规范为设计工作提供了元数据，用户可以看到数据类型，针对资源获得自动补全等功能。

但是光有 REST API 还不够，针对特定应用程序的连接器也极为重要。开发者需要借助连接器连接到遗留系统或没有提供 REST API 的系统。我们的数据库、FTP 和 SAP 连接器很受客户欢迎。

实际地说，仅供应商创建的应用程序连接器和 RESTful API 还不够。MuleSoft 建议客户在核心业务系统和流程之上建立一个 API 层。因为随着应用程序的缩放，直接连接到系统的做法会产生很多副作用：

一个改动就会破坏任意数量的下游集成。

产生系统无法处理的非预期负荷。

降低有关“谁需要访问什么数据”的能见度。

数据安全性受影响。

自行创建 API 使得用户能够实现版本控制、安全性、流量调节、分析等功能，借此解决传统数据集成方法面临的很多问题。

Darren Cunningham（SnapLogic）：没错，用户确实可以雇佣在特定应用和 API 以及系统连接方面具备丰富经验的开发者，但通过平台化的方式实现数据和应用程序的集成可以在维护成本、生产力、业务敏捷度、扩展能力，以及可复用性方面提供长远收益。尤其是智能连接器更能让我们获益匪浅，例如我们所说的 Snap ，易用、可靠，性能卓越。通过充分利用 SaaS 供应商的 RESTful API，Snap 可以对接口进行封装和优化。借此可以为用户提供一个抽象层，使得用户无惧各种变化，不需要成为开发者就能明白一切。虽然原生 REST 连接方式很重要，但 REST 连接器无法实现智能化。另外 REST API 提供了众多可用选项和方法，也许会显得很复杂。SnapLogic 提供了一种利用 REST API 的最佳方式，并将我们的最佳实践融入到 Snap 中。最后，通过使用 Snap，还可以让用户无需担心目标 API 的改动。

我们的客户可以使用多种类型的 Snap，包括企业应用程序（Workday、Salesforce、ServiceNow、SAP）、关系型 noSQL 和云数据库（Microsoft、Oracle、Cassandra、MongoDB、AWS Redshift）、大数据技术（HDFS、Kafka、Parquet）、社交媒体、物联网，以及其他来源、变体和协议。

Jim Harrer（Microsoft）：如果某个 SaaS 供应商提供了 RESTful API，那么 Logic Apps 就能直接使用这些 API（无需编写“连接器”代码就可以直接使用 RESTful API）。话虽如此，通过 Logic App 使用供应商提供的 RESTful API 而非编写 C#或 Java 代码，这样做的目的在于功能的丰富程度和速度。

以往可能需要 6 个月甚至更久才能完成的集成工作现在速度大为提高，通常可以在数天或数周内完成。Logic Apps 可以集中处理身份验证和连接的管理工作，通过直观的指向和点击操作就能对这些 API 进行妥善的编排。此外对这些 API 的访问是托管的，因此可以更方便地跨越不同工作流实现重用。

然而目前集成领域内所使用的很多更有趣的服务和协议并没有提供集成所需的简洁 RESTful API。例如，在处理一些典型的 B2B 工作负载或 VETER 时，通常供应商并没有提供什么简单易用的 API。这种情况下 Logic App 连接器需要通过大量非必需的逻辑实现集成，但这一过程依然可以通过指向点击这样的操作轻松实现。这些连接器托管在 Azure 中，可以轻松缩放。

不同用户对连接器的喜好程度也各不相同。IT 专业人员和集成技术开发者可以使用 Azure 服务总线、SQL 数据库、Dynamics CRM 以及 Azure 存储，而我们的普通集成人员（Citizen Integrator）主要会使用 Office 365、SharePoint、DropBox 以及 Twitter。目前我们已经有超过 35 个流行的连接器，并且每周还有新的发布。

InfoQ：越来越多的接口迁移为 iPaaS 模式，如果要配合本地系统实现低延迟用例，客户该怎么办？

Jim Harrer（Microsoft）：客户在将 iPaaS 与本地系统进行集成时，最常用的方法是直接与系统建立 Azure 混合连接（Hybrid Connection）。如果工作流中的某个步骤要求与位于本地环境的应用程序进行集成，这种方法的效率非常高。如果需要与本地系统的编排和流程进行集成，通常客户会选择使用消息中介（主要是 Azure 服务总线）来实现。本地系统可以监听队列或话题，只要可用就会立刻开始工作。这种异步模式可以抵消云环境造成的任何延迟，而如果需要同步编排，还可以通过 Webhook 或服务总线响应队列发出响应。

Dan Diephouse（MuleSoft）：首先需要注意的是，我们没必要将云和本地环境区分对待。各地的企业都在迁往云环境，公有和私有云之间的界限越来越模糊。很多企业会跨越私有云、公有云，以及传统数据中心将自己的应用程序连接在一起。为了解决这种“模糊”的问题，Gartner 建议实施“由一种或多种解决方案组成，可将本地和云中的集成和 API 管理能力合为一体的平台”，也就是混合集成平台。

这种情况下，低延迟用例不仅普遍而且重要。为此用户首先需要具备一个低延迟的实时引擎。Anypoint 平台使用 Mule 作为运行时引擎，经过多年的优化和完善该引擎可提供极高的性能。我们可以用极低的延迟实现横向扩展。

其次，用户需要能以极快的速度访问所连接的系统。对于公有云，我们可以通过 VPN 连接到用户的其他数据中心。此外用户也可以使用 Amazon 的 Direct Connect 功能直接将自己的数据中心和我们的云环境对接，这样就算面对要求最严格的用例，延迟也不会成为问题。

最后，用户的业务应用程序本身也需要能实现低延迟。大部分应用程序，哪怕云应用，在设计上都没有考虑过这一点。而也正是因此用户会遇到各种问题。Anypoint 平台让这个问题变得更简单。我们提供了数据缓存功能，用户不再需要不停地优化自己的应用。我们还提供了 Anypoint MQ，该功能可以对请求（例如新订单）创建队列，这样后端系统在具备足够容量时就能用更可控的方式处理。

Darren Cunningham（SnapLogic）：恰当的 iPaaS 解决方案必须能提供混合执行能力，同时需要考虑到不同需求下在云中或客户数据中心内进行集成时的数据重力（Data gravity）问题。所用解决方案还应该能应对面向批处理的传统数据集成以及低延迟的实时集成要求。SnapLogic 通过持久的 Always-on 管线响应外部调用，借此实现低延迟。这些“超级”管线都是分布式的，可以通过同一个数据流的多个实例在不同节点上运行，借此实现负载均衡。如果对高吞吐率或低延迟有要求，这种类型的管线可以在本地环境进行横向扩展以处理不同规模的负载。

InfoQ：很多公有云供应商提供的弹性层可以根据系统资源阈值进行动态的横向扩展。动态横向扩展对 iPaaS 解决方案重要吗？如果重要，在消息的耐久性方面会遇到哪些挑战？

Darren Cunningham（SnapLogic）：没错，对于混合执行引擎，iPaaS 解决方案应该具备在云环境中弹性扩展的灵活性，这样客户就不需要为无法预见的需求预先分配资源。合适的平台甚至可以将弹性扩展能力带给本地部署环境，并能以 YARN 应用程序的方式在 Hadoop 集群中原生运行。消息耐久性问题的处理是弹性框架整体工作中重要的一环，通常这种问题是通过缓冲机制解决的，例如使用队列存储消息以解决延迟问题，或使用 Spinning up 计算引擎处理峰值时期的消息。Snaps 中的 Ultra Pipelines 针对这类情况提供了内建的队列机制。

Jim Harrer（Microsoft）：iPaaS 解决方案可以通过自动横向扩展满足工作负载的需求，并在需求降低时回缩。动态横向扩展使得客户无需考虑构建足以应对峰值负载所需的基础结构，并可通过系统监控确保基础结构在峰值时期可以满足需求。消息耐久性通过扩展可满足应用程序对吞吐率的需求。随着系统回缩消息耐久性也不受影响，因为消息内容作为一个单一应用程序无需跨越多个缩放单元。

Dan Diephouse（MuleSoft）：我觉得对于早期阶段的 iPaaS，人们并不会考虑动态横向扩展这个问题。iPaaS 最初只是为了实现“云集成”，主要侧重于 SaaS 应用的后台集成。但现在， iPaaS 的用途远不止如此。很多组织必须开始考虑 API 设计和实现、消息、订单处理等问题。这种情况下，扩展能力、消息耐久性、可靠性，以及持续运行时间就成了极为重要的因素。API 和集成不能忽略任何一个因素，否则就可能失去客户或导致业务无法运转。我们在与客户的直接交流中意识到这个问题：我们的云平台驱动着联合利华、可口可乐这类非常大规模全球化企业的日常业务运转。

我们通过多种不同方式实现了这一切：

无状态（Statelessness）：我们设法让运行时引擎完全与任何状态无关，为消息（Anypoint MQ）和缓存（ObjectStore）构建的服务可独立于运行时单独缩放和管理。

冗余（Redundancy）：我们的所有服务都可通过多个数据中心使用，并且现在几乎每个服务都在多个区域可用。

自愈（Self-healing）：我们的平台可以检测故障，并在需要时通过其他数据中心重新合成运行时环境。

InfoQ：相比传统的本地集成中介（Broker）/ESB，客户换用 iPaaS 解决方案的主要动力有哪些？

Dan Diephouse（MuleSoft）：我觉得原因有两点。首先，为何上云？云平台能为客户提供极高的投资回报，用户不再需要考虑服务器设置、操作系统更新维护、扩展能力测试、为运行时环境推出更新，或为基础结构应用安全方面的最佳实践等问题。对客户来说，这样不仅能大幅节约成本，客户自身可以更加专注于创新而非基础结构。最近与我们合作的一个团队称以前需要花 4 个月完成的供应任务，现在可以瞬间搞定。交付速度和业务从中获得的价值都有显著提高。

另外需要注意，这种全新模式与一些“落伍”的供应商所认为的“我们都把它放在 Amazon 了，当然已经上云了”这种做法有着本质差异。前者是一种多租户环境，能提供多租户环境的所有收益。后者只是一种托管式服务，使用这种服务时依然需要考虑上文提到的那些问题。

另外还有一个问题需要考虑：为什么需要更现代化的集成解决方案？过去 5 年里全世界发生了很多变化，集成解决方案也需要与时俱进：

对于 SaaS，企业需要的是能横跨云应用和本地应用的混合解决方案，这样才能运行“重心”各不相同的工作负载。

世界正在逐渐转为拥抱 RESTful 服务，用户需要具备能帮助自己更轻松地设计、实现、使用 API 的解决方案。否则等于只是在简单地将不同东西连接在一起，无法促进重用，也无法让业务实现预期的效率。

随着 SaaS 应用日益流行，拆箱即用的应用程序连接能力也愈加重要。

不同模式的连接能力正在逐渐统一。大部分客户对应用程序和数据的集成、API、B2B，以及其他方式的集成都有着相互交织的需求。

世界不再以 SOAP/XML 为中心。客户需要的是与具体格式无关的解决方案，而不是将一切转换为 XML 的标准化模式。

很多供应商就是跟不上变化的节奏，只能牺牲自己解决方案的相关性作为代价。

Darren Cunningham（SnapLogic）：传统的集成中介 /ESB 生命周期已经到了尽头。这是一种笨重的，以 XML 为中心的技术，主要针对每几年才升级一次的遗留业务应用程序打造。这些集成技术进行过大量定制，实现、使用和升级过程都很困难，已经难以招架现代化云应用程序的发展步伐和大数据在容量、种类，和速度方面的飞速增长。数字化转型是改为使用 iPaaS 解决方案的主要动力，为了提高预见能力和“实时”运作能力，通常需要采用云计算和大数据技术，并需要重新思索分析基础结构。另外还有其他一些动力，例如速度和敏捷度，以及业务线自助服务等。面向企业的 iPaaS 解决方案必须能提供统一的应用程序和数据集成能力以及极高的易用性，这样才能让更多人开发和管理集成，并且整个平台必须使用现代化标准构建（例如使用 REST 和 JSON）。

Jim Harrer（Microsoft）：我们很明显地看到 CIO 和 CTO 正在敦促企业架构师简化自己数据中心和应用程序的痕迹。首先从服务器（操作系统和补丁）开始，随后专注于应用程序层，因此很多公司受到 SOA 和微服务的启发开始沿袭“API 为先”的心态。随着新的 SaaS 应用逐渐取代本地应用程序，新时代的集成发生在云端，这一点就很符合逻辑了。通过在云中进行集成，企业可以更轻松地管理并缩放，同时享受到只为所用资源付费这一经济效益。我们的客户会使用 BizTalk 实现本地集成，可行的情况下则会使用 Azure Logic Apps 实现 SaaS 到 SaaS 的集成，但与此同时依然可以灵活地使用不同产品之间的原生适配器将不同场景连接在一起。

InfoQ：诸如 Docker 这样的容器逐渐受到企业的关注。容器与 iPaaS 平台是补充还是竞争的关系？原因何在？

Darren Cunningham（SnapLogic）：容器与 iPaaS 平台是互补的。实际上 SnapLogic 为“容器化”的混合云和大数据集成提供了新的功能。这种功能可以帮助客户通过 Docker 容器部署即时（Just-in-time）SnapLogic Snaplex，这是 SnapLogic 平台提供的一种可弹性缩放的数据处理组件。这种 Snaplex 容器可部署在任何能承载 Docker 容器的云环境中，可运行在使用 Docker Swarm、Kubernetes 或 Mesos 的数据中心内。通过这种容器，用户可以快速简便地部署和停用能将服务器利用率发挥到极致的 Snaplex 集群。

Jim Harrer（Microsoft）：我们认为容器与 Microsoft 的 iPaaS 产品是互补的关系。

对于 iPaaS 的核心功能，例如不同业务流程的编排，新 API 的暴露，与业务合作伙伴的集成，或重要业务线系统的连接，容器并不能原生提供这样的功能。容器更为关注的是简化部署工作，在生产环境中管理开发者的代码，因此起到了互补的作用。

我们很多客户的解决方案不仅要使用 Azure Logic Apps 或 API Management 等 iPaaS 组件，还要编写并部署自定义代码。在将这些代码 / 逻辑部署到相应环境（生产、开发 / 测试、产前）时，容器成了管理这些应用程序生命周期的另一个工具。

Microsoft 可以用一种截然不同的方法提供这样的关系，因为 Azure 包含的很多开发工具和托管选项可以无缝连接至 Logic Apps。我们认为这样的关系非常类似于无服务器计算（例如 Azure Functions 或 AWS Lambda）、PaaS（例如 Azure App Service）或 IaaS（例如 Azure 虚拟机或 AWS EC2）与 iPaaS 产品之间的互补关系。

Dan Diephouse（MuleSoft）：对我们来说，容器是一种促进技术。在安全性、可管理能力，以及资源优化方面，容器能为客户提供很多收益。我们的很多客户已经在自己管理的 Docker 容器中运用了 Mule 运行时引擎。同时我们也在努力完善自己的平台，希望让 Docker 能成为我们平台中的“一等公民”。

InfoQ：分析师和供应商的社区中已经逐渐开始接受“普通集成人员（Citizen Integrator）”这个概念。你们觉得这个现象的未来如何？为了管控普通人开发的此类接口，企业需要采取怎样的战略？

Jim Harrer（Microsoft）：我们认为“集成”最终将无处不在，会像用 Excel 表格整理数据那么普遍。今天的信息工作者会在工作中使用大量 SaaS 应用，而通过集成解决方案，我们可以将这些不同服务结合在一起。虽然集成领域的专家可以很好地运用 iPaaS 解决方案，但我们的目标是通过诸如 Microsoft Flow 的 iPaaS 解决方案为普通人的集成工作提供帮助。Microsoft Flow 正是构建于 Logic Apps 基础之上，但它属于一种完善的 SaaS，而非平台服务。这样我们就可以为普通人的集成工作提供可定制的场景。

通过 Microsoft Flow 和 Logic Apps，我们为从 iSaaS 到 iPaaS 的迁移提供了一个平滑的增长路径，通过对集成解决方案进行集中管控，普通人的集成成果很可能最终成为关键业务必不可少的组件。此外我们在 Microsoft Flow 中提供了可涵盖整个组织的管理机制，这样无论普通人创建了什么（哪怕并非关键业务所必须的），管理员都可以对其进行监控和管控。

Darren Cunningham（SnapLogic）：这里的关键是自助服务。现代化的 iPaaS 必须为开发者提供基于 Web 的设计器，而不仅仅是基于 Eclipse 的工具。去中心化模式下可能遇到从高级用户到普通人在内各种类型的用户，因此要在简化用户体验的同时确保不影响处理复杂多点需求的能力。除了安全性、可扩展性以及高性能，iPaaS 解决方案提供商如果不希望只提供简单的点对点用例，还必须专注于提供强大的管理能力，对任何时间里用户可以获得何种程度的功能，可以访问什么内容进行管控。SnapLogic 客户通常会建立一种联盟的共享服务模式，通过一个中央团队确保组织中的其他人员可以通过 IT 管理的自助服务门户实现自己需要的集成。

Dan Diephouse（MuleSoft）：“普通集成人员”这个称呼的问题在于，不同的人对这个概念会有不同的理解。我很喜欢 Gartner 对这个问题的定义，他们将所有人分为 3 个角色：

1) 集成专家（Integration specialist） – 整天的工作就是使用专门的工具创建集成。

2) 即席集成人员（Ad-hoc integrator） – 偶尔需要创建集成，依然是技术人员，通常专注于业务线（LOB）领域。

3) 普通集成人员（Citizen integrator） – 非技术人员。

如果真的想要解决与集成有关的问题，一定要将所有这些角色以整体的方式看待，否则很快将面临一团糟的局面。

例如，作为促进即席集成和普通人集成的一个重要措施，需要确保他们可以访问数据。在为核心系统开放 API 的过程中，集成专家扮演了重要的角色，只有这样 API 才能在业务线中顺利使用。从管控的角度来看这一点很关键，因为你可以通过 API 对数据的访问加以控制，确保下游用户不会因为疏忽造成的负载导致系统崩溃（例如可以应用限速策略），并能强制实施紧密的安全控制，确保底层数据结构的变化不会破坏下游集成。

对于即席集成人员，交付速度很重要。我们提供了大量预配置的模板和范例，帮助他们在有保护的情况下通过最佳实践快速上手。我们的技术帮助他们轻松地通过门户发现可供使用的 API。同时我们还在不断努力开发更易用的工具。

随后可以看看普通集成人员，这里面有很大的潜力。但是在我看来，目前为止他们的大部分操作都只与 iPaaS 有关。简单来说，大部分公司的做法只是通过更为简化的，针对普通集成人员的工具吸引业务用户，帮助他们解决小规模的业务或个人自动化问题（例如在收到老板发来的邮件时发送提醒短信）。用途挺赞，但这样的工具能帮你把 Workday 和公司的福利系统集成在一起吗？或者，能为你的移动应用创建 API 吗？不能。数据转换过程会变得异常复杂。

那么问题在于，如何才能让这种技术能与企业的关联更紧密？目前我们的做法之一是开发了 dataloader.io 。我们选择了一种非常具体的集成任务：数据加载，并努力使其能够被尽可能广泛的用户所使用。这样 IT 就可以从复杂的任务中解脱出来，由业务用户自行完成。另外我们还提供了 Data Gateway ，业务用户可以借此将 Salesforce 连接到 SAP 或数据库。我们认为在跨越三种类型的角色进行简化和协作方面这里还有很大的机遇，同时这也是我们目前关注的重点。

InfoQ：越来越多的接口专为 iPaaS 构建，甚至可以在网页浏览器中创建，测试方面有什么变化？自动化的测试依然很重要吗？

Dan Diephouse（MuleSoft）：测试是无止境的！

也许有人会争论说对于某些“普通集成人员”用例，测试并不重要。没错，就像没有人会对自己的“自动回复”进行测试一样（但是有一次我告诉大家我将有一整年时间不在办公室….）。在软件开发的整个生命周期内，我认为更重要的是要解决“配置”问题，而不是“代码”问题。

这个问题还需要从更宽泛的角度来考虑，不仅仅围绕“测试”，而是要更多地考虑持续交付的问题。开发生命周期内的一切你都想实现自动化，包括测试、推广，以及管控。我们在这个领域进行了大量投入，提供的工具可以帮助用户通过 Jenkins/Maven、 testing 、 coverage reports 等工具更轻松地实现自动化部署。

Darren Cunningham（SnapLogic）：随着更多 API 的出现，“测试”更多地开始针对以可编程方式进行的基于工具的测试（Harness-based testing），而不是传统方式下在浏览器界面中进行的“记录并重现”测试。为了维持敏捷度，对数据流管线进行自动化验证是确保可以对各种改变快速进行回归测试的关键。SnapLogic 管线通过暴露表达式和条件逻辑可以检测数据的正确性。由于管线还可以通过 REST API 调用，因此可以将其轻松捆绑至现有的测试工具中。

Jim Harrer（Microsoft）：如果核心业务操作用到了 iPaaS 组件，那么就一定需要进行自动化的测试并实施强壮的应用程序生命周期管理机制。目前我们将有关测试 / 源代码控制的需求看作“普通集成人员”和 iPaaS 用户之间的一个重大差异。

更具体来说，UX/Web 工具很适合新手上手并了解整个平台，但关键组件最终依然需要考虑源代码控制和自动化测试等问题。目前我们已经看到很多通过 Azure Logic Apps 运行关键业务工作负载的客户开始考虑这些问题。

因此 Azure Logic Apps 支持“代码视图（Code view）”的概念，并可支持通过 Visual Studio（此外还有浏览器中的可视化设计器）和 Azure API Management 将配置 / 策略导出为可存储在源代码控制系统中的格式（并提供了内建的 Git 支持）。

InfoQ：iPaaS 领域的下一个“大事”会是什么？

Jim Harrer（Microsoft）：业务需要在应用程序集成过程中获得更多价值并实现更高速度，因而 iPaaS 的范围和能力都产生了不小的扩张。工作流自动化、API 管理、企业服务总线能力，以及通过托管的方式连接到常见的商用 SaaS 应用，这些能力为 iPaaS 奠定了良好的基础。

然而客户希望能通过我们的帮助实现更多目标。作为对这个挑战的回应，我们已经可以帮助客户轻松连接到超过 50 种 Azure 服务，并通过 Azure 机器学习、Azure 认知服务，以及 Azure IoT 为集成开发者提供更多高价值机会，帮助他们通过工作流实现更大的目标。

这方面最近有个例子，我们一个与全球最大健身中心有合作关系的伙伴需要将会员管理系统与 Marketo 集成在一起。在概念验证阶段，该合作伙伴还将测试数据与 Azure 机器学习进行集成，并开发了一个 PowerBI 仪表盘，借此让客户更详细地查看会员流失情况，包括 Azure 机器学习识别出来有潜在流失风险，很可能会在未来 60 天里退会的会员。这家合作伙伴的表现超出了客户的预期，最终赢得了这个业务。

我们还将继续扩展自己的 iPaaS 解决方案，使其同时支持 Logic Apps、API Management、服务总线，以及通过 BizTalk Server 实现的本地连接，将这些与超过 50 种 Azure 服务结合在一起，通过各种与众不同的机会为客户打造一流体验。我们认为这样做可以通过非常有竞争力的价格为用户提供无限可能。

Dan Diephouse（MuleSoft）：MuleSoft 与客户针对应用程序网络这个概念进行了合作。大部分时候当你与公司建立联系后，都会造成巨大的混乱。脆弱的连接，很少能重复使用。其他人的创新工作无法利用这些数据，最终的结果只能让一切变得更复杂，丝毫不会简单。通过恰当的组织范式（服务重用、访问重用、恰当的 API 抽象），经过一段时间的使用，你将能获得一个可以灵活运用，可重用的应用程序网络。通过以越来越快的速度连接到你的应用、数据，以及设备，同时依然不失管控，创新将获得极大的促进。这是我们目前关注的重点。在短期和长远计划中，我们会继续完善现有的混合 iPaaS 能力，以便为应用程序网络的构建提供更好的支持：从设计工具的扩展到涵盖更广泛的组织开发者，通过网络分析和智能帮助组织变得更聪明，更安全。

Darren Cunningham（SnapLogic）：iPaaS 的下一个“大事”无疑是大数据。截至目前，围绕 iPaaS 的大部分工作都侧重于实时混合云应用程序集成的用例。但应用有限，数据是无穷的。我们会继续看到企业中围绕统一平台的做法进行着汇聚，进而产生大量与以往做法完全不同的集成用例。在多云、大数据，以及物联网时代，我们会看到越来越多的企业 IT 部门开始接受 iPaaS 技术，将其作为数字化转型的关键促进因素。过去 3-5 年里产生的技术将被证明更适合新时代的分析和运营集成要求。

关于讨论者

Dan Diephouse是 MuleSoft 的产品管理总监。Dan 的团队创建并发布了 MuleSoft 的集成平台即服务产品：CloudHub。同时他还负责开发并发布了 dataloader.io，目前唯一可用于 Salesforce 的数据加载器，该工具一经发布就荣登 AppExchange 榜首。