无服务器Serverless将变革工作流BPM

无服务器是基于事件驱动的,那么是不是无服务器只能用来实现事件驱动呢?当需要以低延迟来处理数据流时,函数编程、事件流和事件源是这项任务的最佳选择工具。

但是,只有少数解决方案才能采取真正的事件溯源Event sourcing,并实现“事件回放”。更常见的方案则是比较简单:按照特定顺序对函数和API端点进行一系列调用,在调用之间传递数据,并保存状态。如果错误地将基于事件的编程范式应用于这些简单问题反而使得解决方案复杂化,难以推理,难以调试,并且经常导致反模式,例如将调用顺序和状态转换逻辑放在函数代码中。

而工作流解决方案就非常适合这种情况,因为它们擅长三个关键需求:协同逻辑;在任务之间传递数据;并保持清晰,透明的运行状态。

在无服务器中,工作流不会取代基于事件架构EDA,而是在它们适合的地方进行补充。一个典型的无服务器+事件溯源的例子 - Nordstrom 的“Hello Retail”,这是使用工作流来协调逻辑顺序和保存大部分状态的。

毫不奇怪,所有三大云都急于引入Workflow作为一种服务提供。

Microsoft Azure首先推出LogicApps,它是利用Workflow Foundation, System Center Orchestrator和Powershell Workflows挖掘其在工作流管理方面的专业知识,微软LogicApps创新地实现了之前所谓的不可能,吸引了开发人员和非开发人员。它有一个图形化的工作流编辑器,并得到以程序员范式定义的基于JSON的工作流定义语言的支持,但具有更强大的功能,可以在任务之间发送数据,更不用说有150个随时可用的连接器可与“一切”集成。

亚马逊跟进推出了StepFunctions,放弃了以前所谓的简单工作流服务。急于上市导致了较差的运营经验:例如在修改工作流程时会丢失历史执行记录等,但它的基础亚马逊状态语言是坚实的、简单的。具有出色的数据引用功能和丰富的错误处理功能,包括重试和捕获。简单性需要权衡:它不支持高级工作流模式,如分支和join,只支持顺序和并行逻辑。

谷歌终于也加入了,放弃了“not invented here”的态度,并采用其开源AirFlow工作流程引擎,用于其Google云平台产品和Cloud Composer(这个名称让人想起Extreme Workflow Composer,这是另一个基于OpenStack Mistral的工作流程自动化工具)。AirFlow长期以来一直得到工作流专家的良好评价,它使用Pythonic领域特定语言(DSL)进行工作流定义,围绕有向无环图(DAG)的良好架构,基于操作和挂钩提供可扩展性,以及使用XCom,这是Google的跨任务通讯设施的昵称。你可以在此处找到AirFlow概念的概述

还有一些新的较小的工作流程项目,如来自Fn项目的Flow,或来自我们自己的StackStorm的Orquestra。

如您所见,这些工作流引擎在工作流原语、操作方便性、可调用类型以及扩展性、容易程度方面存在很大差异。存在许多微妙的方式不同。但是它们有一个共同点:它们被用于连接无服务器架构。当谈到无服务器时:通过一些开发努力和独创性,使用它们都可以完成工作。值得关注的两个小块 - 定价和对我们的架构的影响。

当解决方案利用某些工作流功能时,或者在缺乏if的情况下工作时,对架构的影响就会体现出来。例如,LogicApps支持带有'for_each'关键字的“多实例数据”工作流模式,因此可以在工作流级别处理数据数组。StepFunction不支持它,它将处理数组的责任推到了你自己的解决方案级别,或者直接进入Lambda函数。

让我们面对现实:尽管工作流程产品存在功能差异,但优点和缺点 - 甚至是定价 - 都不会成为你选择云提供商的决定性因素。恰恰相反:你可能会选择的云中的工作流服务WFaaS,享受专业人士服务并汲取利弊,就像我们一直使用PaaS一样。除非你想反叛并按自己的方式行事,否则它适用于任何云,甚至是云端。

Multicloud?
多云是否会成为现实?有人说它已经存在了,但是,从不同的云帐户到生产跨云解决方案,充分利用最佳云服务还有很长的路要走。无服务器是将服务和平台粘合在一起的一种方式,但单靠FaaS是不够的。

为了满足需求,Serverless.com推出了Event Gateway,以促进事件溯源发展,促进跨云无服务器解决方案。就是这种解决方案成为现实了,我相信还有一个跨云的工作流即服务的发展空间,这样才能在需要时提供简单的流程编排和状态管理。如果真的会成为现实,Gartner会将其称为XCloud WFaaS。

Serverless and Workflows: The Present and the Futu