• 无服务器计算，或者功能即服务（Functions-as-a-Service，以下简称FaaS），未来将会改变我们的产业链，凡是基于它的企业或者组织，最终会受益于它在价格、人力，以及上市时间等方面带来的竞争优势。
• 许多无服务器应用程序，未来将会对FaaS和其他第三方提供的服务进行组合，以便提供功能预管理和状态管理。
• 工具会有极大地提升，特别是在部署和配置方面。
• 较好的无服务器架构模式稍后就会出现，现在了解细节为时过早。
• 未来需要基于真正的DevOps概念，无服务器可以提供的所有市场效益，最终将会被拥有自己管理能力、自给自足的产品团队所收获。

现在是2017年，距离两年前无服务器计算革新只取得了少许进展（你听见人们在唱歌吗？）。这次变革并不是像Docker那样突飞猛进地前进，而是采用了相对平稳的发展节奏。Amazon新发布了Web Services的Lambda特性，产品保持了一个有规律的发布节奏，另一个重要的第三方（微软）正在一个接一个地发布生产环境版本，也有一些新的开源项目频繁地加入这场盛宴。

当我们接近早期阶段的末尾时，来做一个有趣的游戏，让我们戴上预测护目镜（开个玩笑），深入思考下一步会走向哪里，如何走到那一步，以及我们的组织需要去做什么来支持这一步的到来。所以，加入我们，让我们看看无服务器计算未来可能发生什么。

让读者了解真实的未来！你可以通过阅读这篇文章开始了解细节。我们离无服务器还有多远？2020年怎么样？请寄一张明信片给我！

过去十年我们目睹了云计算的出现，然后它迅速地异军突起。9年以前，虚拟公有云服务器还只是手上的玩具而已，但是在相当短的时间里，当我们考虑任何新的部署架构方案时，它变成了大多数行业的首选平台。

无服务器计算，或者Functions-as-a-Service（Faas），当我们考虑“IT”如何变化时，它会是这次重大变化的最新出现部分。这次变革是一次我们一直以来所期待的自然过程，从我们如何交付应用程序给客户开始，到希望能够删除所有的部件和基础设施。

我们开发的相当一部分应用程序，是由许多小的组件所组成的。每个这样的组件包含了一个小的输入集和上下文信息，需要消耗10毫秒或100毫秒完成组件的一些内部工作，最终可能反馈一个结果，也可能更新相关内容。这类场景最适合无服务器计算。

我们预测未来由于FaaS在部署上的方便、快速、廉价，会有越来越多的团队基于FaaS开发，这样便于管理和扩展基础设施。我们对FaaS可以有很多种使用方式，包括：

• 由大量的顺序消息处理器所组成的完整的后端数据管道
• 通过HTTP API调用的同步服务
• 通过独立的胶水代码提供针对部署、监控的自定义操作逻辑
• 对于计算密集任务，由实体服务器直接调用平台缩放功能组成的混合动力系统

使用FaaS的企业相较没有使用的企业具有竞争优势，包括价格、投向市场时间等。

广泛采用FaaS的一个先决条件是针对快速而简单的状态管理方法的解决方案，或者一系列解决方案。无服务器计算是一种无状态模式。我们不能假定任何有用的状态存在，即不存在即时执行环境内不同的运行时调用之间的有用状态。一些应用程序在这种限制下依然适用。例如，单纯进行数据转换的消息驱动组件不需要访问外部状态，拥有无限制响应时间需求的Web Service组件，其每一次调用时需要连接到一台远程数据库，这种做法也是可以接受的。但是对于其他应用程序来说，这种限制就显得有些不足了。

解决这类不足的一种方案是混合动力系统，即在不同类型的组件里管理状态，而不是执行我们的FaaS代码。比较流行的混合动力方案是通过云端基础设施提供其他服务的前端FaaS功能。我们已经见到了这种类似于API网管的特定上下文逻辑的组件，它们提供了HTTP路由、授权，以及我们经常在典型的Web Service里看到的节流逻辑，采用定义替换配置方式实现。Amazon最近也在管理状态的通用方式上露了一手，使用他们的Step Functions服务，允许团队基于可配置的状态机器定义应用程序。Step Funcations服务本身可能没什么过人之处，但是通常情况下这种无码解决方案是很受欢迎的。

当供应商服务不充足时，对于混合动力系统来说，一种改变方式是团队坚持开发追踪状态的长生命周期组件。这些组件可能被部署在CaaS（容器即组件，Containers-as-a-Service）或者PaaS（平台即组件，Platform-as-a-Service）环境，和FaaS功能协同工作。

这种混合动力系统组合了长期运行的组件逻辑和每一次FaaS功能请求逻辑。另一类做法是完全地聚焦于FaaS功能，让这些FaaS功能超越它们当前执行的环境，极其快速地获取和持久化状态。一种可能的实施方式是确保一个特定的FaaS功能，或者一系列FaaS功能，确保它们拥有类似于Redis这样的外部缓存机制，起到低延时访问作用。通过启动类似于Amazon的same-zone plancement groups（置放组群）这样的特性可以做到这一点。虽然这种解决方案较内存/本地磁盘状态方案来说有些延迟，但是很多应用程序会认同这种解决方案。

混合方法的好处是经常被访问的状态可以和逻辑一起保存在环境当中，那样并不复杂，但是可能有点贵，必须要有逻辑网络选址和外部状态。另一方面，一个单纯的FaaS方式的有点是更加一致性的编程模型，外加无服务器带来的更为宽广的伸缩使用和可操作性优势。当前的发展势头显示最终混合方式会胜出，但是我们也应该对其他方式开放，比如类似于启用置放群组Lambdas。

超越业务管理和状态管理，我们可以预见到其他组件的服务化和商业化，即使在云端环境，传统意义上我们希望开发，或者至少自己管理这些服务。例如我们可以停止运行在EC2机器上面的Mysql数据库服务器，转而使用Amazon的RDS服务器，我们可以使用Kinesis替换我们自管理的Kafka消息总线安装程序。其他的基础设施服务包括文件系统和数据仓库，而更多的面向应用示例包括认证和语音分析。

这种趋势还会继续，我们需要进一步地减少创建或者维护产品所带来的工作量。我们可以设想更多的预安装的消息逻辑（把Apache Camel想象成服务，构建到Amazon Kinesis或者SQS里面），并且进一步开发通用机器学习服务。

这里比较有意思的一个想法是FaaS功能，由于它们轻量级的应用模式，可以将自己紧紧地绑定一个服务，使得FaaS调用服务功能的生态环境时可以调用其他的FaaS功能，诸如此类等等。这会导致“有趣的”级联错误问题，对于这种错误我们需要更强大的监控工具，会在本文稍后介绍。

目前来看，绝大多数的无服务器计算是运行在供应商数据中心平台上的。这就给出了一个替代方案，即如何运行你的代码，而不是在哪里运行代码。Amazon发布了一个有趣的新特性，即是允许它们的客户在不同的地点运行Lambda函数，例如，和Lamdba@Edge一起运行在CDN内，甚至在无服务器地点，例如，和Greengrass一起运行的物联网（IoT）设备。这样做的原因是，Lamdba是一个极端轻量级的编程模型，本质上的事件驱动的，并且非常容易适配相同的知识理念、新地点的代码风格。Lambda@Edge是一个特别有趣的例子，因为它提供了在一个地点进行程序定制的可选项，这在以前是没有出现过的情况。

当然，这种做法的缺点是和供应商深度绑定！对于那些不想使用第三方平台，但是又想利用无服务器计算优势的厂商来说，有一种可以接受的解决方案，类似于Cloud Foundry已经推出的PaaS。来自Kubernetes的Galactic Fog、IronFunctions以及Fission，是这种方案的早期作品。

正如我之前描述的，这里有一个明显的减速，使用无服务器方式时存在条件限制、性价比权衡。天下没有免费的午餐。对于已经过了早期适应阶段的无服务器用户来说，我们需要解决或者缓解这些问题。所幸，这方面目前发展势头良好。

使用AWS的标准工具向Lambda部署函数挺复杂的，也比较容易出错。向API网关中添加Lambda函数，以响应HTTP请求，你更多要做的工作是安装和配置。无服务器和ClaudiaJS开源项目项目已经推动部署改进措施达一年之久，AWSSAM（AWS无服务器应用模型）也在2016年加入到了这一行动。所有这些项目通过在AWS标准工具的顶层增加大量自动化程序，简单化了无服务器应用程序的创建、配置和部署。但是我们还有很多工作要做。未来将会有两个关键动作实现完全自动化：

• 初始化一个应用程序或者环境的创建（例如，初始化生产环境，以及初始化临时测试环境）
• 持续多部件应用程序的交付/部署

第一条很重要，我们也已经开始认识到，以便更广泛地推广“生产提前期概念”。部署一个全新的无服务器应用程序应该是像创建一个新的Github仓库一样容易，填充少量字段，然后按下按钮，通过这种一键部署方式让系统自动创建你所需要的所有东西。

然而，光有简便的初始化部署方式是不够的。我们也需要有比较好的工具，支撑前面提到的混合动力系统的持续交付和持续部署。这意味着我们应该可以部署一系列的计算函数以及CaaS/PaaS组件，连同所有应用程序封装服务的变化（例如，在一个API网关配置http路由，或者一个被单一应用程序使用的Dynamo表），一键生效和回滚能力。此外，这些动作都不应该是很费脑力去理解的，也不会需要几天时间去完成安装和维护任务。

这是一个很艰难的抉择，但是我前面提到的工具（类似于Terraform这样的混合动力工具）正在指引解决这些问题的方式，我完全相信他们在未来的几个月或者几年时间里可以在很大程度上解决问题。

本文不仅仅讨论部署代码和配置服务。其他一些操作上关心的问题也会被讨论。安全问题是一大问题。当前，获取AWS凭证、角色，以及设置和维护都可能是一大麻烦事。AWS拥有一套完善的安全模型，但是我们需要一个工具，这个工具可以让这套安全模型对于开发人员来说更加友好。

总之，我们需要开发人员在开发他们的Webtask产品时，做到UX和Auth0都很好，就像AWS一样的宽广而有价值的生态系统。

一旦我们的应用程序被部署完毕，我们就会需要针对监控和日志的良好的解决方案，这类工具目前有几个组织正在尝试积极地发展着。除了评估其中一个组件的功能，我们也需要号的工具追踪请求，这些请求穿越了一个完整的多个无服务器计算功能和配套服务体系的分布式系统。Amazon正在将X-Ray推向该领域，目前说这个还有点为时尚早。

调试也是挺重要的。程序员很少在第一次代码运行通过之前不犯错误，我们也别寄希望于这种情况会有所改变。我们依赖于监控，在FaaS功能的开发阶段评估问题，但是这种调试方式是石器时代的工具。

当我们调试传统的应用程序时，我们从IDE工具那里可以得到很大的支持，通过设置断点、单步调试代码，等等。使用现代化的基于Java的IDE工具，你可以绑定一个正在运行的远程进程，并且远程执行调试工作。因为我们更加倾向于使用云端部署的FaaS功能完成大量的部署工作，希望未来你的IDE工具也可以具有类似的功能，可以连接到一台正在运行的无服务器平台，查询每个功能的执行情况。这需要工具和平台开发商之间的协作，如果想要让无服务器被广泛采用，这些措施都是必要的。这些想法对于云计算来说有一定开发工作量，也有大量的测试工作量。

我到目前为止所讨论的所有关于无服务器工具的话题，我认为最落后的是测试工具。值得关注的是，无服务器方案较传统解决方案来说有着相当大的测试优势，主要是两点，（a）.无服务器计算的各个功能的单元测试很成熟，（b）.无服务器服务写的代码更少，并且至少在单元测试层面，只需要做简单的测试。

但是这并没有解决跨组件功能/集成/验收/业务流程等测试问题。无服务器计算时我们的逻辑是分散在几个函数和服务内的，因此，更高级别的测试甚至比使用接近单一方法的组件更重要。当我们如此依赖于在云端基础设施上运行时，我们应该怎么做呢？

对于我们来说，测试可能是最没有看清楚的。我猜测未来基于云端的测试会变得很普遍。这一部分会变得更加容易部署、监控，以及调试我们的无服务器apps，甚至于比我现在描述的这些原因更加丰富。

换句话说，为了运行更高级别的测试，我们将会部署整个生态系统的一部分到云端，并且对部署在那里的组件执行测试用例，而不是针对部署在我们自己开发机器上的系统运行测试用例。这种做法有一定的优势：

• 执行部署在云端的组件的真实度较本地模拟来说更高。
• 我们较过去，更有可能可以运行高负载/高丰富度数据测试。
• 生产环境数据源的测试组件（例如，一个发布订阅模式的消息总线，或者一个数据库）会更加容易，虽然显而易见我们需要关注能力/安全问题。

但是这种解决方案也有弱点。首先，执行测试的周期时间很有可能由于部署和网络延迟而相应增加。其次，当网络连接中断以后，我们就不可以继续运行测试用例了（例如，在飞机上）。最后，因为生产环境和测试环境最终部署方案很相近，我们也需要格外小心，当我们打算改变测试用例时，不要发生不小心改变了生产环境的事故。如果我们使用AWS，我们可能需要通过类似于IAM角色这样的工具安全地部署，或者对于不同类型的环境使用完全不同的账号进行部署。

测试并不仅仅是一个二进制程序运行成功或者失败，我们也想要去弄清楚测试是如何失败的。我们应该可以调试本地运行测试和正在运行的远端组件，包括可以单步调试一个运行在AWS上的Lambda函数，因为它可以相应测试。所以所有的远端调试，例如，我前面章节提到的工具也需要测试，而不是仅仅交互式开发。

请注意，我并不是基于这些暗示我们的开发工具需要运行在云端，也不是测试本身需要运行在云端，虽然两者将来都会或多或少地走到这一步。我只是表示正在测试的系统仅运行在云端，而不是一个非云端环境。

使用无服务器作为测试驱动环境可以收获有用的结果。一个例子被称为“无服务器火炮”，这是一种负载测试工具，由运行着的许多并行的AWS Lamdbas组成，执行即时、廉价、易于扩展性能测试规模的负载测试用例。

值得指出的是，在某种程度上，我们避免了一些失误。由于技术进步，传统的高层及测试实际上正在变得不那么重要，例如（a）生产环境测试/使用监控驱动开发，（b）平均解决时间（MTTR）的显著降低，（c）基于持续部署。对于许多的无服务器apps应用广泛的单元测试，度量业务水平的生产环境监控&预警，以及一个专用于减少MTTR和基于持续开发的方法，都将会是有效的代码验证策略。

系统架构较好的无服务器应用程序是怎样的？是如何演变的？

我们正在逐渐看到一些无服务器被有效地应用的案例，即系统架构的学习案例正在逐渐增多，但是我们还没有看到针对无服务器Apps的“模式组”。在2000年早些时候，我们看到了一些这方面的书，比如Fowler的《Patterns Of Enterprise Application Architecture》，以及Hohpe / Woolf的《Enterprise Integration Patterns》。这些书着眼于很多项目，派生出横贯不同领域的通用系统架构知识。

重要的是，在做出统一意见之前，这些书着眼于基础工具几年的使用经验。无服务器技术存在时间太短，还不足以需要编写一本书进行描述，但是这一时刻正在逼近，一年内我们会看到一些有用的实践案例出现（当无服务器架构需要出一本高调的书时，大家一般会选用“最佳实践”这样的术语描述）。

系统架构之后（即无服务器应用程序是如何被构建的），我们需要思考部署系统架构（无服务器应用程序如何部署）。我已经谈了一些部署工具，但是我们可以如何使用这些工具呢？例如：

• 环境这样的术语在世界上意味着什么？“生产”看上去较过去有点不明确。
• 什么是一个软件栈的side-by-side部署？看上去像是从一组功能/服务版本缓慢地移动业务到另一组功能/服务版本（滚动部署）？
• 世界上有么有类似于“蓝-绿”这样的部署方式？
• 现在的回滚方式是怎样的？
• 我们如何管理数据库的升级/回滚，当我们可能有多个不同的代码生产版本，并且这些版本在同一个功能内运行，这类有状态组件应该如何管理？
• 当使用第三方服务时，如果你不能够完全下线服务或者重新完整地部署，那么一台phoenix-server看起来更像什么？

最后，当我们从一种系统架构样式迁移到其他架构，什么迁移模式是比较有效的？或者是否包括无服务器组件？我们的架构以怎样的方式进化？

许多这些尚未定义的模式（反模式）都不是很明显的，通过我们幼稚的想法明显表现出来的是，如何最好地管理无服务器系统内的状态。毫无疑问，有一些神奇的模式出现了。

成本效益是无服务器前进的一项驱动，最有意思的优势是“生产提前期概念”的降低。通过提供“超级能力”方式，无服务器为大多数既不是系统管理专家，也不是分布式系统开发专家的美国工程师提供了进入无服务器领域的可行性。这些只有一点点技术的应用程序开发工程师，不再需要编写一行Shell脚本，即可完成整套MVP（即Minimum Viable Product，最小可行性产品）的部署，扩展平台能力，或者配置一个nginx服务器。前文中我提到了配置工具还在开发当中，我们现在还没有这类“简单的MVP”解决方案，能够解决所有类型的应用程序问题。但是，我们确实看到了相对于简单的Web Services服务，甚至为其他类型的应用程序部署一些Lambda函数，也比管理操作系统进程或者容器来得更容易。

除了MVP以外，我们也看到了重新部署应用程序的周期时间正在缩短，不再需要关心脚本维护、系统补丁级别，等等。

无服务器为我们提供了技术手段去实现这些需求，但是还不足以真正实现对于一个组织的改进。为了实现这些目标，公司需要去克服、适应以下这些变化。

DevOps已经在很多领域都变得很重要了。在开发工作上，额外技术的技术操作越来越常见。我所看见的是系统管理内部的自动化增加和自动化测试，这只是Patrick Debois在创造DevOps概念时所想到的很小一部分。

真正的DevOps是我们思维方式上的变化，以及文化上的变化。让我们假设有这么一个团队，这个团队需要紧密合作、开发和维护一个产品。这就意味着写作，而不是基于协商的工作序列方式。也意味着开发人员需要提供技术支持。而意味着开发工程师需要参与应用系统架构。换句话说，意味着技能与责任的融合。

如果一个公司分离了开发团队和运维团队，即将“DevOps”团队分离，那么他们不会在无服务器领域有任何收获。如果一个开发人员仅仅只是对应用程序进行编码，而部署工作又交给另一个外部团队负责，那就会没有真正意义上的系统部署情况反馈。如果一个业务工程师不会到应用程序的部署环节，那么他们也不可能适应生产环境的部署模型。

换句话说，未来会从无服务器领域收获实际收益的公司，必然是真正使用DevOps的公司。

即便一个组一个组地尝试改变文化，也是做得不够的。很多时候，一个大公司里的一个很有工作热情的团队，往往面对的是冷冰冰的公司政策。这可能意味着在缺乏外部批准的情况下，缺少部署新系统的能力。很有可能是由于对于所有现有应用程序的数据访问限制。也可能是因为超级严格的支出控制。

虽然我不提倡公司把所有与安全和成本相关的问题抛到外部解决，但是为了尽可能做到无服务器化，需要调整他们的政策，允许团队对操作请求作出改变，而不是每一次小的更新操作都需要一个团队外部人员的批准。访问控制政策目前还不是很有必要构建。团队需要被给予一定范围内的预算自由。所有的实验应该被尽可能多地提供免费的沙盒，同事还可以保护公司内部真正敏感的数据或其他需求。

通过我之前提到过的IAM规则和多个AWS账户的使用，访问控制工具正在逐渐完善。然而，不是那么简单的，针对更好的自动化方式正在成熟。同样，无服务器还存在通过几个账户实现基本预算控制，我们需要更容易控制每个团队执行能力限制，对于不同的环境有不同的执行限制范围。

好消息是通过加强权限控制工具，所有这些问题都有可能解决，我们会看到y预算分配模式上的进步，等等，因为无服务器工具在持续改进。事实上，我认为访问自动化和成本控制将会变成新的shell脚本，换句话说，当团队思考suanfa软件的操作问题时，他们不会想要去开始/停止脚本、升级补丁以及磁盘使用率，反而他们会严谨地思考他们需要怎样的数据访问方式，以及需要怎样的预算。因为团队将会经常需要思考这个问题，工程师们会用自动化取代这些问题，仅仅像我们之前做部署那样。

鉴于这种能力和严谨性，未来即便是数据最敏感的企业，也会有富有热情的团队会使用无服务器技术，使用它们去尝试自己的想法，这种做法是之前在白板上从未做过的，最终他们会认识到这种做法真正意义上保护了他们的知识或者避免财务损失。

过去几年时间里我们看到的另一个转变是许多高效的工程团队的聚焦正在从项目专项产品。这一转变的感觉是对于项目规划、迭代和燃尽图等的关注在降低，转而更加关注看板方式的进展、轻量级预估以及持续交付。比这一结构性改变更重要的是虽然角色和心态在转变，转变为更多的职责较差，同样我们看到真正的DevOps。

举个例子，现在很有可能产品经理和开发人员将会密切地充实新思路，开发人员会做一些原型，产品经理在最终产品设计方案明确之前，会深入进行一些技术上的数据分析。相似地，创新的火花，即新的想法或者概念也会进入某人的大脑，可能属于团队中的任何一个人。这个团队的许多成员，不仅仅是一个，现在正在接触到客户喜欢的想法。

无服务器方法为这些团队提供了一个关键好处，即接受整个团队产品思维。当团队中的任何一个人都可以想出一个点子，并且迅速地针对一种尽可能新的创新模式实现一个原型。现在精益启动式试验变成默认的思维方式，而不是由“黑客时代”保留的那样，因为这样做的成本和时间正在大幅缩减。

另一种看待这一问题的方法是，不接受整个团队产品思维的团队很有可能错误这一关键利益。如果团队不鼓励超越项目结构的思考方式，他们就很难尽可能多地使用无服务器所带来的加速交付可能性。

无服务器在软件架构领域相对来说是一个新的概念，但是它也是一个可能和其他云计算创新一样，具有巨大影响力的技术创新。随着技术的发展、工具提升以及无服务器应用架构方面的心得交流，越来越多的工程团队将会拥有提升开发速度的工具，甚至于可能转变他们产品开发方式。适应无服务器，并且适应支撑该技术的文化，这类公司将会在未来领导我们前进。

感谢为此文贡献知识的朋友们：John Chapin、Chris Stevenson、Badri Janakiraman、Ben Rady、Ben Kehoe, 以及Nat Pryce。

英文原文：The Future of Serverless Compute