紧随其他各大云平台供应商的脚步,IBM 也期望在逐渐成长的无服务器计算(serverless computing)方面有所作为。因此,IBM 为他们的 Bluemix 平台推出了一个全新的事件驱动编程服务,名为 OpenWhisk 。今年三月,IBM 公司于拉斯维加斯举办了 InterConnect 2016 大会,在会上宣布推出 OpenWhisk 这项服务。该服务的设计目标是在发生某些外部事件,例如在收到传感器数据时执行用户自定义的代码,作为对这些事件的响应。
InfoQ 与 Bluemix 的架构师之一 Michael M Behrendt 进行了一次访谈,内容涵盖了对这次会议的感想、以及与 OpenWhisk 和 Bluemix 相关的一些问题。
InfoQ:让我们直奔主题吧。能否请你从事件驱动应用以及虚拟机(VM)这两方面为我们描述一下 Bluemix 平台上的计算模型?
Michael M Behrendt:我们在 Bluemix 平台上提供了一系列不同的计算模型。最底层的抽象模型是 VM,在其之上是容器以及 Cloud Foundry 应用,最上层的抽象模型则是通过 OpenWhisk 实现的事件驱动应用。需要指出的是,这些模型不存在“好”与“坏”的区别,因为在我看来,每种模型都有各自最适应的场景。从 VM 直至事件驱动应用模型,其内置的管理能力也有所上升,这使开发者能够摆脱一些繁重的任务,但随着控制粒度的下降,对于流程执行控制的灵活性也随之下降。
Bluemix 中所提供的容器服务属于后一个层面的抽象模型,它允许开发者设置 Docker 容器,而无需关心底层的操作系统。这种方式的限制在于开发者需要受到容器 host 所使用操作系统的约束。
Cloud Foundry 应用是比容器服务再高一个层面的抽象模型。在这种模型中,开发者只需专注于应用的代码,并将代码推送至 Cloud Foundry 平台。该平台将负责设置用于托管应用实例的容器、自动配置负载均衡层,以及健康管理等等。与容器服务相似,开发者受限于 Cloud Foundry 所使用的操作系统,以及对应用程序特征的特定假设。
最后一种抽象模型 OpenWhisk 同样能够让开发者专注于应用程序本身的代码,但这种方式对于应用代码的架构会进行更多的假设。OpenWhisk 的优点在于它是一种非常粗粒度的执行模型,并且内置了扩展与冗余能力。如果系统不存在任何事件或是需要进行处理的请求,则在内存中不会运行任何代码。随着事件的不断传入,将有越来越多的行为开始执行。在这种模型中,开发者无需考虑如何运行多个进程以实现冗余能力。
InfoQ:Bluemix 主要是基于 Cloud Foundry 所打造的,但它的模型已经发生了变化。这是否意味着这个平台无法兼容不同的提供商?
Michael M Behrendt:并非如此。正如之前所说,我们的目标是为用户提供选择的自由,让他们选择最适合自身需求的方案。也就是说,用户可以同时使用 OpenWhisk、Cloud Foundry、Docker 容器与 VM,并且这些技术之间不会互相干扰。不过,我们仍然为这些不同的模型提供了某些一致性,以实现某些基础的功能,例如 Common ID,这是一种通用的路由层,可实现通用的服务调用功能。
InfoQ:你能否介绍一些关于 IBM Bluemix OpenWhisk 的更多技术细节?
Michael M Behrendt:OpenWhisk 中主要包括三个关键的概念:触发器(Trigger)、规则(Rule)与行为(Action)。触发器代表你需要进行响应的任意场景,例如数据库中的一条新记录、GitHub 中的一次提交、或是某台移动设备进入了某个地理围栏(geofence)。
行为则是或大或小的代码片段,用户需要在 OpenWhisk 中注册这些行为。可以通过 Node、Swift 或 Java 等语言编写行为,也可以由 Docker 容器中的任意二进制文件进行定义。当某个行为被调用时,相应的代码会立刻被部署至一个容器中,并在执行后立即销毁。行为的调用越多,行为的部署次数也相应地增加,以此实现系统的可伸缩性。OpenWhisk 将负责管理部署文件,并以智能地方式对容器进行缓存(这一点对于最小化部署时间至关重要)等等。行为既可以通过 HTTP 调用直接执行,也可以是在 OpenWhisk 平台上由某个触发器通过某种规则所执行的行为。当触发器启动时,相应的行为就会直接被调用。在实现 OpenWhisk 引擎时,我们使用了 Scala、Kafka、Docker 以及其他各种技术和库。Scala 用于实现 OpenWhisk 本身的核心引擎,Kafka 则用于在执行行为时用于 OpenWhisk 内部的消息处理。我们还使用了 Docker 作为执行行为的底层容器机制,并且保证了这些行为的隔离性。
InfoQ:OpenWhisk 是否实现了开源?Java 开发者是否能够在 OpenWhisk 平台上进行开发?
Michael M Behrendt:是的,OpenWhisk 已经完全开源了,它的项目托管在 GitHub 上,基于 Apache 2 许可。并且我们已经收到了来自外部的 pull request(热情欢迎每一位的参与:-)。我们目前为 Node 与 Swift 提供了原生的支持,并且正致力于实现对 Java 的支持(编辑提示:OpenWhisk 现在已经提供了对 Java 的支持),并且在未来将支持更多的语言。此外,我们还支持将 OpenWhisk 中所运行的 Docker 容器作为行为,这为开发者提供了非常高的灵活性,因为只要是能够在 Docker 容器中运行的任意二进制文件都可以作为行为使用。
InfoQ:Bluemix 预期中的使用者是哪种类型的组织?是创业公司还是大型企业呢?
Michael M Behrendt:如果组织希望在云计算平台上构建、运行以及维护现有的产品以及新开拓的产品,那么 Bluemix 就是一种合适的选择。在我看来,无论是创业公司还是大型企业,这种需求已经成为了一种共识。开发者在这两种环境中的表现、他们的工作方式、所使用或准备使用的技术都已经具备了很大的共通性。
我认为,大型企业会有一些额外的特定需求。举例来说,出于法律或数据存储位置的原因,他们需要对于应用程序的部署地点具有灵活的选择。我们将通过一些不同的部署模型,即专用 Bluemix 与本地 Bluemix 实现这种灵活性。此外,大型企业往往需要访问现有的应用程序与数据,因此我们在 Bluemix 中提供了大量的集成功能。
InfoQ:让我们讨论一下 Docker,或者说容器技术与平台即服务(PaaS)这两者之间的比较吧。你认为这两种技术是互斥的还是互补的呢?
Michael M Behrendt:从最底层的角度来说,容器是一种具有极高通用目的的技术,它允许你对任何功能进行打包并运行。因此,容器可支持大量现有的工具与软件,并支持各种不同类型的协议,例如在集群中使用的内部协议以及各种外部协议。在我看来,容器是 PaaS 构建的一种核心元素,但 PaaS 还提供了一些额外的、预先集成的功能,例如负载均衡以及健康状况管理。PaaS 同时遵循某些应用程序架构,例如 12 要素原则。因此,如果你从使用原始的容器这种做法转变为使用 PaaS,那么你将能够利用各种预先集成的功能,从而得以专注于你自己的代码,但也因此失去了某些对细节的控制能力。这种比较最终是一种在内置的管理功能与可控制能力之间的权衡。在我看来,不能简单地说你的某种选择是对是错,答案取决于你所运行的产品类型。
从技术的角度上说,我认为整个行业需要确保从原始的容器到 PaaS,乃至事件驱动计算这样的路线对于用户应当尽量做到无缝地衔接。现在来看,我认为这些领域中还存在着太多的技术壁垒,这一方面使我们这个社区无法实现理想中的高效率,同时也使得用户的选型与实施变得更加困难。
InfoQ:最后,让我们来讨论一下 IBM Interconnect 大会吧。以架构师、开发者或 DevOps 的角度来说,从这次大会中能够学到些什么?此外,你能否谈论一下 Bluemix 的未来?
Michael M Behrendt:在我看来,这次大会所强调的重要信号在于 IBM 既关注于将现有的产品迁移至云计算平台,同时也致力于在创建新应用程序方面的创新。举例来说,IBM 与 VMware 的合作以及 Cloud
Connect 这个服务的宣布就属于对现有产品的支持,而对于 OpenWhisk 的宣布以及我们与 Apple 共同开发的服务端 Swift 等服务就更专注于新应用的开发。今后,我们将继续推动 Bluemix 的发展,这与我们在过去几年中所设立的技术策略相一致。我们将继续专注于提供最全面的、高度一致的计算模型选择,以及数据、分析、集成、认知以及移动等方面的服务。此外,我们将以开放的形式发布这些服务,为客户提供更自由的选择,使他们能够在这三种集成交付模型中进行选择,即公开、专用以及本地模型。
在 Interconnect 网站上可以下载 Michael M Behrendt 的演讲内容,以及其他各场演讲的内容。
查看英文原文: Q&A with Michael Behrendt on IBM’s Event-driven Programming Service Bluemix OpenWhisk
评论