Serverless 平台的下一步

在 2015 年，我们发布了 Serverless Framework, 以帮助开发者通过优秀的 Serverless 计算服务（例如 AWS Lambda，也被称作 FaaS）来构建应用。

这个框架已经成为 Github 上成长最快的开源项目之一，也是大众关注 Serverless 发展的主要焦点。我们的计划/项目引领着整个行业：所有人都可以在此追溯用例以及孵化浪潮。

这给了我们洞悉 serverless 的进展之所以强大的原因，同时也留给了我们它将走向何处的线索。

之前

当我们在 2015 年第一次介绍这个框架后，我们吃惊的发现有很多企业排着队来试用。

这些早期的采用者是叛逃自微服务、容器以及传统云架构的皈依者。他们在寻找一个庇护所，以避免现代软件开发复杂性——令人生畏的各种工具、最佳实践、维护成本以及各种常见的鼓动宣传 “如何构建 XXX” 的宗教战争。

当对 “Serverless” 这个术语的定义还有一点争议时，早期的采用者们并不关心这些争议。工程师们只是不顾一切地希望将产品推向市场并降低管理费用。而 “Serverless” 这个词向他们允诺了一种走出这条路的技术。 不要服务器（serverless）是一个能引起共鸣的信息。

少即是多 —— Serverless 社区团结在这样一句格言下。人们想要的是更多的产出，而不是更多的技术。

便捷带来使用

在 2015 年末，工程师们开始在各自的 team 中进行 Serverless 的概念验证。早期试验的成功驱使着他们检查自家业务的每一段逻辑并且发问，“可以上 Lambda 吗?”

初期的 Serverless 用例均由数据处理来主导。但是突然间，工程师们将所有类型的工作都用 Lambda 塞满：使用 Serverless 计算来构建后端并且自动化工作流程。他们捣鼓出了自动伸缩、按需付费和最小开销或者说最小管理的微服务。效率的提高的太过诱人以至于让人无法忽视。

尽管一些 serverless 计算早期的限制可能变成前进的的障碍，但是工程师们依旧选择妥协或者寻找变通的办法。云厂商们急忙通过没完没了的补丁和新功能来解决这些限制。这火热的场面给了 Serverless 优先的工程师们一剂强心针。

为了充分发挥 serverless 架构的潜力，社区中需要一个独立的，能兼容各个服务供应商，带来统一体验的，封装好部署函数和管理生命周期的框架。

回到开始的问题，“可以上 Lambda 吗?”，如果答案是不，公司依旧可以带着乐观的前景继续推动，并且道 “什么时候可以上？” （译注：可以类比各大公司等着上 Docker 一样来，看国外的公司等着上 Lambda。）

Serverless 计算承担并消除了原本占据工程师日常的大部分管理任务。这些额外的空闲时间开始在新项目和创造性的思维中发挥作用。各种各样的项目浮出水面：聊天机器人、DevOps 自动化、文件操作器、policy enforcers、webhook 监听器、HTML 渲染器、定时任务，等等等等。

在传统结构的会议中，谈话通常是关于管理；而 serverless 的会议通常是在庆祝产出。

Serverless Team 的发展

Serverless 项目完成后出现了一个有趣的情况：它的（大部分）工程师可以自由地开展新工作。

在个大公司内部，粗犷的 Serverless 先驱者获得了追随者，并组建了第一批非官方的 Serverless 团队 —— 尽管规模很大，团队仍然非常高效。他们经常作为独立单位运作，机动性地实践，并在任务中冒险，以 Serverless 的方式解决新的工作。

截至 2016 年底，在 Serverless 框架发布仅一年后，大厂中的几个卖力团队已经投入了数百个 Serverless 函数到生产环境。

Serverless 优先

管理者们注意到了。 顶级业务领导者一直在追求渐进式的数字化的产品目标。 他们希望比竞争对手更快地进行创新，并立即投放市场、验证且反复这样。

业务 leader 们开始关注 serverless 架构以获得竞争优势 —— 一些 CTO 甚至选择构建自己的 serverless 原型以加快购买速度。 甚至那些没有拥抱过公共云的大型企业都想直接使用 serverless。

他们认为 serverless 是一个更易于上手的云，这也使得大规模团队通过 serverless 相比公共云容易转变为重量级云工程师团队。

目前

Serverless 运动的势头，激励其他的供应商提供自己的 serverless 计算服务。现在讨论 serverless 再也不仅仅是指 AWS Lambda 了。

现在有 Azure Functions、Google Cloud Functions 和 IBM Cloud Functions (基于 OpenWhisk), 以及为特定用例提供服务的小型供应商, 例如 Twilio Functions、 PubNub Functions、 Auth0 Webtask。还有一些使用 Docker 和 Kubernetes 构建的 serverless 计算实现，例如 Kubeless 和 Fission。

较大的提供商正在推出数十种新的托管服务和 API，如 Google 的 Speech 和 Vision APIs，以及 AWS 的 Lex 和 Polly 服务，与 serverless 计算很好地结合，并且基本遵循 serverless 的价值观。

主流云供应商的功能竞争速度正在加快。 与此同时，开发人员和组织也越发的欣喜，市面上越来越多的工具可以用来解决更多问题和传递更多的创新。

操作化的时机

Serverless 的拥护者希望标准化 serverless 开发，以便其他人可以在他们的整个组织中采用它。

一个很显然的需求是，我们需要更好的工具来支持 serverless 的开发和生命周期管理。 不同的组织已经为此采用了许多特定平台的解决方案（如 AWS CodeBuild）, 但是这个过程可能还存在一些犹豫。 捆绑供应商会降低灵活性，特别是他们在运行时和选择自己的生命周期管理工具方面。还使得用户很难将这些特定供应商的体系结构转移到另一个供应商。

因此，对于面向 serverless 的团队而言，serverless 框架已成为其开发方案中不可或缺的一部分。

激励多云

在 Serverless 发展的过程中，一个意想不到的结果出现了。我们发现 Serverless 利用云服务就像上传一个函数一样简单。 需要采用一个云供应商？贴一个函数就好了。 此外，serverless 函数是自动缩放和按操作付费，这意味着在多个区域，甚至多个提供商中配置函数都是很简单的。

很明显，serverless 计算是一个将所有的服务和平台粘合在一起的一种途径。而 AWS Lambda 是被认为最早将 AWS 的服务聚合在一起的例子。 这种绑定功能为多云和混合云架构提供了一个有趣的选择。

这确实激发了一个令人兴奋的讨论， serverless 架构到底应该是什么样子。鉴于它们可以可以一次部署在任何地方，我们是否应该继续以特定于平台的方式考虑 serverless 架构？此外，如果 serverless 架构是通用的，那么这对数据意味着什么？

未来

现在供应商之间还没有标准化。为了充分发挥 serverless 架构的潜力，社区中需要一个独立的，能兼容各个服务供应商，带来统一体验的，封装好部署函数和管理生命周期的框架。

而 Serverless Framework 恰巧做了这样的工作。它是第一个为 Serverless 架构提供应用程序模型的工具；现在，它是第一个提供统一体验工具，支持在所有 Serverless 计算供应商上部署和管理 Serverless 函数。

但是我们依然需要 Serverless 标准。每个供应商都有不同的设计，如函数签名等，这使得技术选择和可用性有一定挑战性，但是本没有必要这样。

Serverless Framework 背后的团队正在与云原生计算基金会和主流云供应商合作，以实现 Serverless 概念的标准。讨论仍处于早期阶段，但所有利益相关方都进行了非常协作，包括大型供应商。

关于函数…... 和事件

关于 serverless 的故事到目前为止主要集中在函数上。然而，这只是上半场。

下半场是关于数据的 —— 由于 Serverless 架构基本上是基于事件驱动的计算，因此它们的数据以事件的形式表示。

现在，Serverless 函数使我们能够轻松地对任何事件做出反应，一切都开始看起来像一个事件：业务事件、应用状态变更、同步请求、异步请求、通知、消息、审计（audit trails）、系统日志、报错、metrics、警告、webhooks、clickstreams、健康检查… 对于 serverless 函数而言，世界充满了各种事件，只需要等待执行和分析。

事件使得数据可移植并且流动。通过 serverless 函数协调的简单契约，且不关心函数位于何处。当开启 vendor 选项后可以避免绑定供应商。如果说有什么独立模式，可以为各个组织在未来几年创造的大量逻辑带来秩序，那么它一定是事件驱动模式。

不幸的是，现存的事件驱动工具和服务处于一个杂乱的状态。在未来，这些工具和最佳实践必须不断进化，以维持我们现在能够获得的生产力水平。（译注：否则随着 Serverless 函数的不断增多以及逻辑逐渐复杂，生产力可能会不升反降）

近期，基于 Serverless Framework 的团队宣布了一个新类型的开源基础设施，名为 事件网关（Event Gateway）。该技术混合了 API Gateways 和 Pub/Sub 模式 来创造一个针对 Serverless 计算的非常高产的事件路由。

事件网管是 Serverless 时代缺失的中间件，并存在能成为现代数字业务支柱的可能。 它的首要目标是以事件的形式表达所有数据（甚至是原始HTTP请求）。 第二个目标是将这些事件路由到任何 Serverless 计算供应商。

事件网关将使得各个团队能够轻松地跨云服务商（或内部部署）编写 serverless 函数并调用它们。

Serverless 平台即将跟进这个计划，它将提供跨 serverless 应用和供应商的团队协作，并提供时间数据管理的解决方案。当然，所有这些工具都将遵循上文中讨论的 serverless 标准。

全面的自动化和智能

自动化迎来如期而至的显著增长 —— 鉴于日益增长的复杂性和成本，必然的发展。为了在竞争激烈且成本高的时代中茁壮成长，每个组织，团队和个人都需要自动化的力量。

随着自动化程度的提高，智能系统也将兴起。 新的架构允许实时的、上下文的数据处理，并让业务出现问题后及时做出更好的调整。

Serverless 计算和 Serverless 架构可以实现这些场景，并且不能低估它们的潜力 —— 特别是当您将自动伸缩的 Serverless 函数的易用性与事件驱动设计的组织能力相结合时候。函数和事件是我们一直在期待的两个简单概念，可以用于构建庞大的自动化和智能系统，同时最大限度地减少运维开销。

这只是 Serverless 架构和 Serverless 整体故事的开始。虽然潜力是无穷的，但要发觉这种潜力，我们需要新型工具和基础设施来构建/运行这些下一代架构。

以上是我们在 Serverless Inc 搞的事情。

译文出处：https://www.zcfy.cc/article/what-s-next-for-the-serverless-platform