InfoQ 虚拟研讨会：无服务器计算的实践方法

主要结论

• 无服务器函数最适合运营成本居高不下，但并不必要的场合。开发者通常会借助这种函数开发新应用，而非将现有应用重建为无服务器模式。
• 无服务器函数通常能让需要大量计算的应用获得最显著的成本收益，但无法保证通过采用无服务器架构就能在计算方面节约更多成本。
• 可将代码连接至需要捆绑在一起的服务。目前的无服务器产品虽然能提供很多便利，但往往是专有的，会导致与其他相关云产品的紧密“锁定”。
• 可以在概念证实阶段多花一些时间，看看无服务器技术是否真的最适合你从事的项目。

开发者在构建软件过程中需要掌握各种技能，而这长长的清单中又要增加无服务器计算这样一个技术了。无服务器产品（更严格来说可以称之为函数即服务产品）虽然更简单，但需要付出代价。在转换为这种无状态的异步范式之前，开发者需要了解哪些信息？企业在选择相关服务后，该如何评估任何可能的，或者实际存在的平台锁定问题？为了近一步了解这个激动人心的领域以及可能产生的影响，InfoQ 采访了该领域的三位专家。

• Joe Emison，Xceligent 公司 CIO
• Kenny Bastani，Pivotal 公司 Spring 拥护者
• Fintan Ryan，RedMonk 公司行业分析师

InfoQ：感谢大家参加今天的虚拟研讨会，我们这就开始吧。如果假设大部分企业（尚）不具备成熟的事件驱动的架构，无服务器函数能否直接替代大部分现有组件？在向自己的环境中引入这种函数时，开发者和运维人员需要了解哪些现实情况？

Kenny Bastani：据我了解，无服务器函数并不能直接取代现有组件。我觉得在 FaaS 的采用方面我们有两条路可以选择：全新应用，以及根据需求为现有工作负载提供补充。

对于全新应用，构建无服务器应用程序可大幅降低实验成本。企业或 IT 可能有很多想法希望尝试，并且可能已经具备了进行尝试所需的开发资源。但直到现在，关键资源的滥用依然是尝试新想法过程中最大的障碍。对于关键资源，我是指基础架构和运维。在托管企业应用程序过程中，现有运维流程所产生的基础架构和支持成本通常实在是太高了，难以支持持续不断的实验。无服务器应用程序为企业提供了一种可能，使得他们能对原本无法承担的新想法进行尝试。如果某些新想法最终失败了，也不会因为成本导致其他还在进行的业务关键项目受到影响。另一方面，如果某个想法最终大获成功，业务也可以更轻松地付诸更多资源。

另一种接受无服务器技术的方法是根据需求为现有工作负载提供补充。此类工作负载是指那些不一定需要长时间运行，也不需要在本地环境中长期存在的工作负载。例如某种用于在第三方 SaaS 产品和本地托管应用程序之间移动数据的功能。无服务器函数可以只在需要时调用，提供将两个系统连接在一起的集成任务。这样的函数可以使用 SaaS 供应商提供的开发者 API，通过本地环境中提供的触发器将数据插入或更新至第三方系统。

Joe Emison：我倒是觉得，如果你有基于微服务的架构，那么就可以将整个微服务替换为一个或一群无服务器函数，取决于微服务本身的规模大小，这样的无服务器函数可能是微不足道的。例如，我构建了基于服务器的微服务，单页 Web 应用（SPA）会调用这些微服务拉取 SPA 所需的内容，而这些微服务是基于服务器的，这样做的唯一原因在于 (a) 需要隐藏凭据，并且 / 或者 (b) 应对服务端点的 CORS 问题。在这些情况下，使用无服务器函数取代微服务并不会造成太大问题。但除此以外的其他情况下，我也很赞同 Kenny 的说法，整体式应用程序实在是没要迁移为无服务器函数。

但 Kenny 提到无服务器函数可大幅降低实验成本，这一点我不能苟同。我觉得他夸大了不使用无服务器函数的情况下执行实验的成本，同时也低估了无服务器函数服务所面临的痛点，哪怕目前处于支配地位的 AWS Lambda，在这方面也有很多问题。

大部分实验（和开发工作）都发生在开发者的工作站（笔记本）上。我（和我的团队）无时无刻不在尝试各种新想法，但在对这些想法的可行性进行验证的过程中，从不需要借助其他部门的帮助。在我曾经就职过的几乎所有企业里，甚至一些财富一千强和政府机构中皆是如此。至少从我过去 3 年 -4 年的经历来看，评估工作的速度并不是什么大问题。

另外我还发现，从初创公司的角度来看，Lambda 其实是个非常让人苦恼的技术，而在对想法进行验证的过程中，这恰恰是最需要速度的地方。你需要使用数量多到难以招架的服务（IAM、API 网关、DynamoDB、SNS、SQS 等），而这与快速启动并测试这一目标恰恰是背道而驰的。如果你所在的企业允许你们使用 Lambda，那么大概也会允许你们使用 Heroku 或其他类似服务（Digital Ocean？如果只想用 AWS，那就考虑 Lightsail 吧），相比 Lambda，这些方式更著名，而启动和测试代码的过程也能更简单一些。

我觉得无服务器函数最适合运营成本居高不下，但并不必要的场合（例如直接成本或时间成本，或机会成本），通过省略需要维护的服务器，我们可以大幅降低此类成本。如果已经有某个应用程序（哪怕很小的应用）开始变得僵硬停滞，或因为你所在的组织要求自行运维和支持并向客户提供服务而导致成本高到难以承受，此时无服务器函数可能才是一种更好的选择。

对于目前这种使用无服务器函数开发大型新应用的做法，我还是比较谨慎的。准确来说，我是指无服务器函数的规模过大的情况。如果你要开发一个大型的原生应用或 SPA，并且这个应用已来少量无服务器函数，其实我在过去 18 个月已来也在这样做，这种做法我是推荐考虑的。但如果我正在规划的某个应用的后端 / 中间层很有可能包含 10,000 行以上的代码（哪怕是在运用了无服务器函数的情况下），那么我绝对会避免选择无服务器技术。毕竟我们对这种方式的开发和架构模式还不是非常了解，随着应用原来越庞大，我们又该如何规划它们的构造呢。有很大可能导致最终的产物完全不可维护。

Bastani：我不是反对别人的经验和观点，只不过我们考虑问题时都有自己不同的角度。我的观点主要源自从不同领域业界专家身上学到的经验。在主持过今年 GOTO Chicago 的 Serverless 活动后，我从那些使用无服务器技术进行持续实验的人口中了解了很多第一手经验。尤其是 Mike Roberts，他在 Martin Fowler 的网站上撰文介绍了有关无服务器和 FaaS 的定义。他在 GOTO Chicago 的演讲中谈到了无服务器技术对持续实验的促进，不仅可以帮助开发者在自己计算机上进行测试，而且有助于承载真实用户所使用的生产应用。如果缺少提供反馈的用户，那么实验本身也就毫无价值。在技术的帮助下开展实验是一回事，向客户持续交付实验性的产品和功能才是更重要的事情，无服务器技术对此大有裨益。

至于 AWS Lambda，我本人就在大量使用，当然我也承认，要使用这种技术，用户需要具备一定的能力。因此我通过实验打造了一套参考架构，可以帮助用户使用自己的无服务器函数彻底代替 AWS 的服务。这种情况下，用户可以创建一个由无服务器函数组成的“微型代码库”，使其成为用户自己的微服务应用程序的“源”，而 Spring Boot 就是这样的产品。我们可以使用 Concourse 持续交付有关无服务器函数的变更，并能注入其他平台上管理的第三方服务的凭据，例如 Cloud Foundry。

最后，曾经我还有机会向财富百强企业中，使用 AWS Lambda 构建实验性应用程序的开发者说过，就算你实际遇到的情况与他人的观点不符，也并不一定意味着那就是不可能的。

Emison：我的意思并不是财富百强企业不能使用 Lambda 做实验，而是说我在没有使用 Lambda 的财富一千强企业中，也并没有看到实验过程中遇到太大的痛点。即：我觉得 Lambda（或无服务器函数）并不能大幅促进我们的实验过程。试验工作通常发生在开发者所用的开发计算机上，无服务器函数（至少就我过去的经历来说）并不能在我们目前基于 Heroku 以及传统的 AWS EC2 进行的实验和测试基础上起到多大的帮助。我也见识过很多财富一千强企业，可以在不依赖运维的情况下进行各种效果很好的测试和实验。

听到 Mike Roberts 提及他认为 Lambda 能够超越传统的，基于虚拟机和容器的方法，随着实验的进展不断地部署代码，这一点固然很有趣。他的文章使得他所谓的“实验”收益仅限于组织已经通过使用核心 AWS 服务实现了的各种简单的函数。另外值得注意的是，他提到了无服务器在敏捷开发方面所带来的收益，此时还特别提及了我在 Serverlessconf 活动中的讲话，而我那场讲话的重点在于 Serviceful 架构（与无服务器函数截然相对）。

Bastani：我觉得你在这里有一个误解，也许你清不清楚持续实验到底是什么。这个概念来自 Etsy，是指能够使用持续交付的方式对假设进行验证（AB 测试、实验性功能等）。如果客户觉得这些功能没用，那么还可以随时回滚。

这里的一场演讲谈到了Etsy 的持续实验。此外 Mike Roberts 也进行过一次不错的演讲。

Emison：刚看完这个视频。我发现大致内容与我在首届 Serverlessconf 大会上就同一个话题所做的演讲极为类似（而 Mike 也在他的文章中引用了我的观点，下文我会给出链接）。

尤其是他举的例子更像是围绕 Serviceful 而非无服务器函数（他也举了跟我一样的例子：Firebase、Auth0 等）。他非常关注如何恰当地进行产品 / 产品管理（这也是我关注的中心），以及恰当的 CI/CD。粗略统计了一下，在整场半小时的演讲中，他只用了 1 分钟 -2 分钟来谈无服务器函数。相比无服务器函数，他对非指责性事后调查（Blameless postmortem）似乎更在意。

因此我实在看不出他的讲话如何解决我们所讨论的核心问题：无服务器函数如何改变整个行业，或是继续使用 Heroku 或其他类似的基于容器或类似于容器的技术进行快速测试 / 快速从创意到部署的过程。

我要反复重申我的观点：我觉得无服务器函数最大的价值在于与生产运维有关的“成本”真的非常高（包括机会成本和依赖成本）的情况。

Bastani：我应该早点看看你的演讲，感谢提供链接。

我对你最后两句话有完全不同的看法。

诸如 Heroku 和 Cloud Foundry 这样的平台在很多方面与无服务器技术极为类似。这些平台都能为开发者提供部署应用，但无需考虑服务器的设置和管理等工作的新方法。当然，它们最大的差异在于成本模型的不同。现在，开发者已经可以创建需要长期运行，不需要始终运行，但依然始终可用的工作负载。这就在企业环境中促成了一种全新的用例，需要考法者用心思考。

Fintan Ryan：目前我们见到的大部分 FaaS 部署都针对新开发的应用，需要某种类型的基本事件处理能力和初始情况下的任务“卸载”。虽然 FaaS 的其他用法也有很多例子，但大部分大规模应用程序正在逐渐转为这种相对来说更简单的用例。

截至目前我们还没有见到有谁使用 FaaS 大规模代替遗留应用的原有组件。但在一些已经才用了微服务方法的应用程序中，一些较新的应用确实通过这种方式取代原有组件了。

最终来说，尽管 FaaS 也只不过是适合某些类型工作负载使用的另一个工具，但为了正确使用，用户必须满足其他很多条件。目前的用户群依然过于偏重于技术本身，在良好的软件实践方面做法还算是合理。

InfoQ：一起来进一步讨论一下 Joe 有关成本的看法吧。人们在谈论无服务器技术时，往往会提到的最重要的特征之一就是“只需要针对实际使用的资源付费”。对于调用频率低或高的服务，计算成本方面的节约（相比使用虚拟机或容器实例）对于哪种情况更显著？还是说这个问题被人们高估了，真相其实如 Joe 所说，“成本”更主要是围绕运维成本自身？

Emison：我觉得调用频率低的服务无法从无服务器函数中获得任何成本收益（同时我也觉得这些服务也无法从无服务器函数中获得有关架构或上市速度方面的收益）。Digital Ocean/Vultur/ 甚至 AWS Lighsail 确实是很便宜的选项，但这个“便宜”仅限运行小流量代码时。就算从可用性的角度来看，为了让这种代码实现高可用，也可以用非常便宜并且简单的方法实现（例如多区域 RDS 以及用两个应用服务器搭建负载均衡器的情况）。我们都知道，类似这样的系统很容易维护，也可以相当容易地通过顾问 / 新的开发者来管理它们。

密集型，尤其是无法预测的密集型计算，才能真正通过无服务器函数获得巨大的成本收益，尤其是实际需要执行的处理任务很容易封装（例如封装成单个函数），并且最多只需要几分钟就能执行完成时更是如此。很多人会对这种情况使用 Hadoop 流，但相比将大量内容塞进 Man/Reduce 逻辑而仅仅只是为了实现 Hadoop 在故障转移和调度方面实现的收益，无服务器函数可以更好、更简单地适应这种情况。

另外要注意，调度本身也可能产生极高的成本，例如在某些情况下，我们可能需要调度（如所具备的计算资源太少，无法满足需求），而调度的管理通常非常昂贵（人员、机会成本、不确定性造成的成本、开发 / 部署解决方案所产生的时间成本）。无服务器函数为我们提供了一种便宜到不可思议的做法，可以“根据所用计算资源付费”，并且可以获得无穷无尽的资源，因此我们无需考虑调度工作，进而可以消除调度方面的成本。

话虽如此，我依然认为计算的成本被夸大了，而人员相关的成本严重缺乏重视。有无数次我听到有人问“我们该如何降低 Amazon 的账单金额”，但同时又说无法缩减 IT 工作，而 Amazon 账单金额的降幅至少能抵消一名全职员工一半的薪水。我们目前所处的时代几乎已经无需大量（甚至全部的）系统管理员、网络管理员，或数据库管理员，大部分组织如果能在云计算和云自动化方面加大投入，（按照最佳实践的要求）缩减用于基础架构维护方面的工作岗位，应该能活得更滋润。

Bastani：我认为，将“成本”相关的话题看作无服务器技术接受条件的做法需要区别对待。我曾听一些 AWS Lambda 的早期接受者说过，相比他们迁移前所用计算架构，无服务器架构最终的成本反而会更高。新系统的计算成本将会高到无法承受。因此他们最终又重新迁移到原来的系统。所以说，无法保证采用无服务器架构就一定能在计算方面省钱。甚至可以说随着时间的流逝，计算的成本将变得更加难以衡量，就算一段时间里的需求难以准确预测一样。如果流量激增，那么计算成本必然也会激增。

在无服务器技术的接受方面，有关成本的讨论应该更加侧重于这种技术对于当前架构能够起到的补充作用。因此比较好的做法是问自己一些问题，例如“无服务器技术如何帮我更快速将新功能交付给生产环境？”，或者“无服务器技术是否可以让整个架构在长期范围内更易于维护，帮我减少技术债？”大部分此类问题的答案完全取决于模块化设计本身。如果架构本身不够完善，长期来看一切都只会变得更贵。

InfoQ：大家已经逐渐就“锁定”问题达成了共识，无服务器平台给人的感觉貌似是，代码本身是可移植的，但会有很多辅助服务把你捆绑在某个平台上。你们同意这一点吗？这个问题重要吗？对于在无服务器技术领域还没有最终确定选择哪家平台的用户，为了维持所需灵活性又该怎么办？

Emison：我认为辅助服务只是问题的一部分，并且目前仅 Amazon 会面临这种问题。Amazon 已经将 Lambda 全面融入到自己的生态内，因此如果不使用两三个（甚至五六个）其他 AWS 服务，你根本无法真正使用 Lambda。并且该服务也只有在 Amazon 的生态内才会发挥最佳效果。此外对于 Google Cloud Functions 等同类服务也存在类似情况，这个服务也需要配合 Firebase 使用，而 AWS 并未提供能与 Firebase 匹敌的类似服务（Dynamo 目前相比 Firebase 还有很大不足），因此这也成了 Google 的锁定元素。

除了辅助服务，用户实际使用的代码、具体使用的框架、代码库中的组织方式，以及部署的方法，这些也很容易导致被锁定到某个 FaaS 框架。例如很多 Lambda 用户会选择 Serverless 框架，很多人还会选择通过 Lambda 执行各种 Linux 代码。从 Lambda 以及 Serverless 框架进行切换的成本非常高，尽管如此，我们还需要假设要切换到的目标 FaaS 平台可以支持你使用的语言 / 代码。

我觉得，对于 FaaS 来说，供应商锁定问题远没有以前我们在架构方面遇到，并且始终相伴的供应商锁定问题严重。原本我们遇到的锁定问题是指：应用程序会变得越来越难以增添和调试，越来越难以有针对性地培训新的开发者。从本质上来说，FaaS 只需要一种微服务架构，而在大范围内来看，每个函数都可以看作自己的微服务。因此我们并不需要将所有函数读入一个整体式的代码库（尽管我们对于如何组织这些内容已经有了完备的风格指南，并且开发者已经很熟悉了），我们所拥有的实际上只是一个大型的函数集合，并且很有可能并不具备整体连贯性和对各种内容进行解释说明的文档（例如可参阅 The Register 针对英国航空关键路径中的 200 个系统撰写的这篇报道）。

另外需要补充一点，我认为 FaaS 将表现出与 15 年前所经历的数据库规范化类似的过程，作为当时的最佳实践，所有人都在寻求真正的第三范式 (Third-normal-form) 数据库结构。现在我们不必那样做了，因为那样做会造成不可维护的垃圾，进而很难以为其编写足够好的接口，或将数据导入其中。相反，现在出于理智，我们会选择性地对数据库进行去规范化（至少会在数据库表中使用枚举值而非 Lookup 表）。在 FaaS 软件开发领域，我们也即将经历一次“函数泛滥”的过程，就像我们会在数据库结构中遇到 350 个表一样，我们也会在一个应用程序中遇到 350 个函数，而原本在一体式应用程序（或并非基于 FaaS 架构，但具备妥善构造的微服务）中可能只需要 75-100 个函数。

这其实意味着，面对这种情况，维持灵活性的最佳做法是减少 FaaS 平台中实际使用的代码数量（当然也要降低应用程序的循环复杂度）。我觉得，使用诸如 RDS 或 Firebase 这种优质的服务本身没有任何问题，通过这些服务可以获得竞争优势，谁在乎它们是否专有技术？但面对目前的 FaaS 平台，我们应当，并且有必要避免构建任何需要调用大量不同函数的大规模应用，否则我觉得你肯定会在 18-24 个月内后悔。

Ryan：我觉得 Joe 一阵见血地指出了架构重构所面临的问题，稍后我也会谈到这点。

关于辅助服务，我们当然有很多顾虑，但对于 Joes 刚才指出的问题：对大部分正在大规模使用 FaaS 的人来说，只要能从中获得任何优势，目前这远远算不得什么大问题。诸如 RDS 和 Firebase 这样的产品，尽管成本高并且会造成锁定，但从长远来看有助于节约简化运维和维护。很多与我们交流过的 FaaS 重度用户很乐意进行这样的取舍，至少从中期范围内，他们更愿意通过这种产品获得效益方面的收益。

从架构的方面来看，如果不进行妥善的思考，以一致连贯的方式编写，并构思好恰当的结构，混乱的代码依然是混乱的。目前业界有这样一种趋势：将复杂的东西用大量不同函数来代表，并搭建出最终的应用程序，而真正棘手的问题并未实际解决，只是转嫁给了应用程序的管理人员。

Bastani：曾经有段时间，我认为必须配合使用 FaaS 供应商提供的辅助服务，这种做法是一种神话。不久前，我决定使用 AWS Lambda 和 Cloud Foundry 做几个兼容性实验。实验的结论之一是，对于部署在 AWS Lambda 中的函数，完全可以使用 Cloud Foundry 托管的服务。

我不同意 Joe 的意见：必须为 Lambda 使用 AWS 的其他服务。但我也理解为什么大部分人觉得必须这样做。首先，AWS 使得我们会自然而然地在 Lambda 函数中使用 AWS 地其他服务。其次，Lambda 可用的事件源大部分都与其他 AWS 服务有关。但实际上，在所部署的 Lambda 函数内部，使用诸如 Concourse 这样的 CI/CD 工具来筹备由 Cloud Foundry 提供的服务凭据，这种做法完全是可行的。我们甚至可以在不同函数的调用之间缓存第三方服务的连接信息，这就让一切都变得可行了。

在可移植性方面，对于 Cloud Foundry，我们将能获得一种可移植的抽象，并在多个云供应商的服务基础上运行。这是因为有一种名为 BOSH 的底层工具可以与不同供应商的 IaaS 通信。如果要更换供应商，可以借助 BOSH 将虚拟机移动至其他供应商处。而 FaaS 的可移植性恰恰麻烦在这里。

以面值来看，Lambda 似乎是一种平台服务。也就是说 Lambda 并不是在 IaaS 层进行的资源抽象。我认为这样的情况是有原因的。因为 FaaS 的执行模式使用了一种独特的成本模型，作为一种资源，函数不能成为 IaaS 的一部分。也正是出于类似的原因，我们不会使用容器作为 IaaS 的核心抽象，而是会使用虚拟机。FaaS 如此独特的原因在于，作为一种服务，只有在能够控制底层 IaaS 的定价模型时，才会显得可行。此外我们在供应商处托管的代码本身是可移植的，这一点与容器中运行的代码一样。只要所连接到的服务是可移植的，那么你的函数本身也就是可移植的。

我建议将代码连接至愿意被锁定到的服务。如果使用诸如 Cloud Foundry 这样的平台解决方案，那么无论 IaaS 层用了什么，你依然会面临被锁定的局面，但说实话，完全没必要被锁定到某个底层供应商。

Emison：需要澄清一点，我之前说必须配合 Lambda 使用 AWS 的其他服务时，我是指为了创建一个可从 Web 访问的端点，我们至少需要使用 IAM 和 API 网关，否则代码将不可达。而如果需要针对一系列用户进行任何类型的身份验证随后才允许访问，那么还必须使用 Cognito。如果希望使用任何类型的状态，那么还需要写入并读取数据，这过程中可能要用到 S3、Dynamo，或 RDS。如果使用了多个函数，那么最终几乎不可避免还要同时用到 SNS 和 SQS。如果要调试，那么至少需要使用 X-Ray。而这是设计使然，AWS 实际上就是一系列 IaaS 微服务的集合，AWS 投入了大量时间和资金（以及合作伙伴的帮助）才使得我们可以拥抱并接受如此大量的服务，才能让自己的生活变得更丰富一些。

Bastani：感谢你的澄清。没错，IAM 和 API 网关是必须的。身份验证可由发起调用的应用程序进行。如果你使用了 Spring Boot，那么也可以通过 API 网关调用这些函数，同时依然在 Spring Boot 应用程序中管理安全问题。然而我依然认为，安全问题应该在函数内部实现，这一目标已经由一个名为 Spring Cloud Function 的新项目做到了。对于 SNS 和 SQS，可以从 Cloud Foundry 将访问凭据注入函数，借此使用自己的消息中介 (Broker)。这种方法最主要的问题在于，必须使用一个始终在线的事件源，例如 Spring Boot 应用程序，借此调用 Lambda 函数作为对插入到队列中消息的响应。在这种架构中，Spring Boot 应用程序将成为事件源。

InfoQ：各位在无服务器平台上更喜欢使用哪种编程语言？同时请注意，目前仅 Node.js 同时得到了 AWS Lambda、Google Cloud Functions，以及 Azure Functions 的统一支持。在无服务器的思维模式下，大家是否更看重这种或哪种语言的某个特性？你是否又更希望看到无服务器平台能对哪种语言提供更全面的支持？

Emison：我越来越坚信 JavaScript（尽管有着各种不足）终将胜出，既然无法战胜，不妨与它联手。我更愿意选择用 Coffeescript 这样能够转换成 JavaScript 的语言来编写代码，这是为了避免各种麻烦的问题。或者制定好严格的风格指南和 Linter，然后尽全力吧。

JavaScript 也在逐渐适应无服务器平台，它具备各种函数要素（尽管并不是函数式语言），至少比 Web 开发常用的其他语言，如 PHP、Ruby，以及 Python 更适合。我这么说是指，在编写无状态函数方面，使用 JavaScript，感觉比使用 PHP、Ruby 或 Python 更自然。

我猜测真正的函数式语言也许更适合用于 FaaS 平台，并且我也清楚，至少 Lambda 针对 Clojure 代码的使用提供了一些教程，但为什么选择一个如此少的人可以胜任的语言，你一定得有一些强有力的理由……

Ryan：JavaScript 目前是最流行的，但 Python 也在迎头赶上。我们还看到有人在 AWS 以及其他更新的平台，例如 Funcatron 上使用不同形态的 Java。

我认为目前 Java 8 提供的第一类函数可以帮助大部分企业开发者更轻松地转换至无服务器模式。对于追赶时髦的人，肯定也会有兴趣尝试 Go（例如使用 Sparta 框架），但所有与 Go 有关的技能目前并不普及，这可能也会拖累转换过程的其他方面。

最后也不能低估 C#，Amazon 没有打算让它成为“一等公民”，但这种做法着实费解。

Bastani：我觉得 Joe 和 Fintan 已经把最重要的问题说清楚了。但我想要补充的是，如果要编写复杂的函数，包含多步序列化数据库事务，而上一步的结果会影响到下一步的处理时，JavaScript 就有些麻烦了。这是因为至少就 AWS Lambda 来说，函数要求在执行完毕后回调作为参数提供给入口点的另一个函数。

考虑一下吧。对于 Node.js 中实现的异步流控制，需要追踪入口点的回调函数，随后将该函数传递给每个异步的方法调用。当然，我们可以将回调方法分配至全局变量，但这种做法似乎有些违反 JavaScript（或任何其他看重这一点的语言）的模式。每个数据库事务同时也是一种异步方法，因此如果需要按顺序处理两个事务，那么就需要将每个回调函数作为参数进行嵌套才不会丢失最开始的那个。我已经发现在实践中，这种方法会造成眼中的逆差，最终只能试着通过日志语句对流控制进行调试，而在回调函数异步级联的情况下，日志也变得千疮百孔。而这种问题的症状就是：你的 Lambda 函数会直接超时，完全无法判断调用结束前流控制到底进展到哪一步了。

虽然也可以通过一些方法解决 JavaScript 的这种回调问题，但每种方法都需要取舍，需要以模块化函数易于维护的特征作为代价。

InfoQ：对于开始接触无服务器函数的开发者和系统管理员，需要事先做些什么，大家是否有什么建议？他们是否应该深入研究事件驱动的架构模式？决定有关编排的策略？设置 CI/CD 工具链？

Emison：我会注册 webtask.io 学习这里提供的非常基本的教程（如果你对 Node.js 有经验，或者说具备 Linux 开发经验，那么就可以在五分钟内构建并部署一个 Hello World 应用），此外还建议学习他们的 Slack 教程，通过这些教程可以帮你在五分钟内构建一个聊天机器人。这些都是免费的，甚至在等待电话会议开始的间歇就可以轻松完成，借此你可以立即体验到无服务器技术的概念和强大之处。

随后我建议阅读 Mike Roberts 撰写的文章，本文已发布在 martinfowler.com。Mike 对于这种技术的利弊，以及入门前需要考虑的问题已经谈的很清楚了。文章不长，在决定花时间研究无服务器技术之前绝对值得一看。

快速（并且老实说，非常）轻松地完成上述任务后，建议访问 serverless.com，这里提供了各种很棒的快速上手指南和演示，以及全面的文档（可从这里着手）。大部分“严肃”的部署都和这里提到的很像，也需要面对本文涉及的各种复杂问题（不过 Serverless 框架可以很好地改进这些问题）。

接着我建议将足够的时间用于概念证实阶段，看看无服务器技术是否真的比你目前使用的技术更有价值，而不要急着按照各种炒作去体验哪些所谓的炫酷技术。

Ryan：除了 Joe 的意见，我只想补充一件事：着手前一定要准备好 CI/CD。

对于任何严肃的生产部署，着手进行前都有必要慎重考虑与编排有关的问题，不过目前编排方面的选项本身也极为有限。

Bastani：Joe 提供的清单是快速上手的不二之选。

我建议任何希望学习无服务器技术的人，首先通过能从中感受到乐趣的应用着手进行实验。例如我所接触过的，最有趣的无服务器函数的用例之一就是对话接口（即聊天机器人）。 Amazon Lex 是一种用于构建语音或文字聊天机器人的对话接口。对于这个服务，我最喜欢的一点就在于它提供了一些原本在客户端相对来说无法实现的功能，并将其融入了一种编程模型中，并在无服务器环境中逐渐完善。Lex 很棒，因为它解决了很多原本就最适合无服务器架构的问题。对于希望了解无服务器技术还能在哪些方面让我们获益的人，Lex 的编程模型提供了一个绝佳的试验场。

我最后一个建议是：无服务器并不是万灵药。当你的执行模式变成真正意义上的“云为先”后，CI/CD 以及测试之类的工作将困难重重。在开发环境中维持快速反馈环路，这依然是提高开发者生产力的关键。当你将执行模式迁入云端，并且开始需要对多个无服务器函数的部署进行协调时，那就先从小的变更开始测试吧，你将很快失去在本地环境快速迭代的能力。

无服务器技术可以帮你以更快速度将代码部署到生产环境，但也可能延长在本地对变更进行迭代所需的时间。

关于本次参与讨论的专家

Kenny Bastani是 Pivotal 公司的 Spring 开发拥护者。作为开源技术的贡献者和博客作者，以及富有激情的开发者，Kenny 参与了各种社区活动，涉猎领域从 Graph 数据库到微服务，五花八门。同时他也是 O’Reilly 出版的 Cloud Native Java: Designing Resilient Systems with Spring Boot, Spring Cloud, and Cloud Foundry 一书的合著者。

Joe Emison是一名科技型创业者，最近的一次创业活动是 2008 年成立的 BuildFax 公司，同时他还为其他很多公司提供与上云和迁移有关的顾问咨询服务。Joe 同时还负责 Xceligent 的所有技术和产品管理工作，并会定期在 The New Stack 以及 InformationWeek 发表有关软件开发和云计算的文章。Joe 以英语和数学方面的学位毕业于威廉姆斯学院，同时在耶鲁法学院获得了法律学位。

Fintan Ryan是 RedMonk 的行业分析师，这是一家专注于开发者的行业分析事务所。Fintan 的研究主要侧重于与开发者有关的一切，从工具到方法论，再到软件开发的组织架构问题。他在 2016 年的主要研究领域包括云原生计算架构、数据和分析、软件定义的存储、DevOps，以及机器学习。同时他也是一位广受赞誉的主题演讲人兼嘉宾主持。

作者： Richard Seroter ，阅读英文原文： InfoQ Virtual Panel: A Practical Approach to Serverless Computing