对话无服务器专家 Luca Mezzalira：你真的为 Serverless X AI 做好准备了吗？

无服务器架构是当下云计算领域最热门的趋势之一。据统计，只有 35% 的技术人员还没有使用无服务器平台，越来越多的企业出于降低成本、简化运维、加快产品上市速度等原因选择转向无服务器架构。那么，开发人员该如何转变自己的开发方式以适应和充分利用无服务器架构？在业务快速变化的情况下如何采用无服务器架构加速应用开发进程？Serverless 架构如何与 AI 等应用场景进行高质量的结合？

亚马逊云科技 TechTalk 特别版直播活动荣幸的邀请到了亚马逊云科技首席无服务器专家 Luca Mezzalira，他结合亲身经验为开发者提供了无服务器架构下应用开发的实用建议。

InfoQ：无服务器架构的核心价值是什么？亚马逊云科技的无服务器架构有哪些优势？

Luca Mezzalira：“无服务器”这一概念经过多年演变，如今我们称其是一种策略。用户采取无服务器策略时可以将同质化的繁重工作交给亚马逊云科技，自己专注编写开发新功能，满足你的客户需求。

无服务器架构有几个优势：首先是业务敏捷性。无服务器架构的优势在于模块化，我们能够在基础设施层面来将这一概念付诸实践。基于无服务器架构，客户可以享受到亚马逊云科技内置的各种通用模式。

无服务器的另一大优势就是我们拥有丰富的基础设施管理经验，客户可以直接享用我们多年来学到的所有最佳实践，而开发人员或整个企业就可以专注于自己的差异化竞争优势——也就是他们的软件或他们正在开发的项目。

InfoQ：您提到了无服务器架构的这么多优势，但任何事物都有两面性。那么在您看来，无服务器架构现在面临着哪些挑战？我们又该如何应对这些挑战呢？

Luca Mezzarila：事物确实都有两面性，特别是对于那些第一次接触无服务器服务的人来说，想要上手确实得花点功夫。大家要在多个维度上转变自己的思维，抛弃过去自己熟悉的传统开发方式，转而在代码层面开始习惯模块化表达，同时试着将更多权力下放给基础设施。确实我们为了上手要花点时间，但这并不是多难的事情。

InfoQ：在无服务器架构中，冷启动延迟非常重要，也是一个常见的问题。Amazon Lambda SnapStart 可以将冷启动时间降低 90%，这绝对是了不起的成就。你能分享一下这背后的故事吗？

Luca Mezzarila：Amazon Lambda SnapStart 特别关注 Java 的应用场景，因为世界上有很多组织都高度依赖于 Java。将来的 Amazon Lambda SnapStart 也可能适用于其他环境，因为 Amazon Lambda 支持多种由亚马逊云科技托管的运行时。

很多开发者都很担心冷启动问题。但根据我个人在行业内工作了 20 年的经验，其实并不是所有 API 都必须拥有超低的启动延迟。大家一直在努力让自己的软件达到最好的效果。但我们还是应该先弄清楚瓶颈究竟在哪里。

我们每年推出的版本中总有一些功能会帮助大家改善自己的工作体验，而且开发者和公司完全不用改变自己的工作习惯。他们一早醒来，会突然发现软件的延迟有所降低。这是种非常奇妙的体验。

InfoQ：在开发无服务器应用时，有哪些好的实践和策略可以提供更好的性能？

Luca Mezzarila：有几个手段是我们可以重点关注的。我们可以从模式出发，以不同的视角看待问题。比如，当我们的解决方案其中有一部分是同步，而另一部分是异步时，同步的部分需要根据传入的请求来扩展，方案的其余部分可以保持较低的扩展度，从而降低维护难度。传统单体架构中，你往往需要优化峰值流量、预先配置基础设施等，但无服务器架构下这些资源都是开箱即用且可以按需扩展的。

我还特别推荐大家认真观察并思考自己在做的工作，想想有什么可以优化的地方。比如说有一些 SLA 或功能可以和产品团队讨论，只要一些简单的调整就可以更加充分地利用它们，让开发者的工作更轻松，同时给用户带来显著影响。

无服务器技术的高性能和稳定性往往是由细节决定的。现在你不用再操心在哪里使用 circuit breaker，在哪里存储内存信息，而是直接借用成熟方案，而且不用自己去维护它们，这样你就可以专注于那些真正重要的任务。

InfoQ：您说易于使用和易于维护是非常重要的，那么您能和我们分享一下如何将应用程序划分为小型、独立的功能模块，并利用无服务器架构构建和部署这些模块吗？

Luca Mezzarila：当我们谈到分布式系统时，主要的挑战在于建模部分。有些公司先是针对细碎的服务做出一些非常小的模块，然后再尝试耦合；还有些公司则是先构建一些小体量或模块式的单体架构，然后当他们对新技术有更深刻的理解时再进一步拆分它。我认为第二种模式效果最好，尤其是当你不太确定你是否想采用微服务时。

有一些实践可以帮助你理解如何拆分应用。首先我推荐大家了解一些领域驱动设计的知识。研究这种技术的社区提供了很多极具启发性的方案和一些能够帮助你拆分应用的工具。例如事件风暴就是一个很好的起点。首先，业务部门和技术部门通过事件风暴会议携手合作，并且只关注用户的整个使用流程。大家在白板上罗列出用户为了完成某一项或多项任务所必须经历的所有事件，这样就可以直观展示使用应用或特定功能的整个流程，看到促成流程推进的关键事件。它们代表着不同任务之间的边界，接下来我们就可以顺利地将各部分工作分配给各个团队。

这时团队已经可以从业务的角度出发，对自己想要表达的内容有了比较清晰的认知，并且可以将其付诸代码。然后团队就可以轻松地把一个个环节映射到无服务器服务上。而如果没有事件风暴这一环节，直接不管不顾开始写代码的话，你很可能会在代码的构建、重构和删除上浪费大量时间。

第二点，我们不应该过早开始预先设计，你不需要在开始写代码前几个月就开始构思准备。你应该采用一个非常精简的方法，在有限的时间内收集尽可能多的信息，然后根据掌握的信息做出决定。有时你很有可能要改变原本的设计方向，而无服务器是在基础设施级别实现模块化的，所以我们就可以直接删除或丢弃一些代码，然后沿着更适合我们软件的新方向前进。

此外，事件风暴的另一大亮点是你可以看到各个团队在与哪些人交流，以及服务中的各个部分在与哪些服务沟通。这样架构师就可以轻松调整架构，改善团队沟通机制，对整个系统的认识也会更加清晰。

InfoQ：我们谈了这么多关于无服务架构的内容，但我们知道在这个领域另一项非常重要的技术叫做微服务。那么您对这两种架构之间的关系有何看法？您认为一项技术会取代另一项吗？

Luca Mezzarila：微服务只是一个术语，表示一个特定的实体或工作单元，而且它是完全独立的，可以由单一团队管理。微服务要有一个强大的封装。而这个强大的封装可以是由各种方式设计的，可能是代码，可能是某种基础设施。我认为无服务器应该算是微服务的一种表现形式。现实应用中并不存在它们之间的硬性分割，大家完全可以用容器、虚拟机或者无服务技术等各种方式来实现微服务。

真正重要的是我们到底想用模块化微服务表达什么。很多 API 其实根本没有那么高的要求，也许我们只想用它获取数据和查询数据库，这时候无服务器也是个好选择。但无服务器可能并不适合每一个负载，所以大家不必盯着一套方案到处使用，这反而会限制你做架构优化的能力。

在设计系统时，我们需要考虑太多因素，包括成本、性能、可扩展性和可靠性等等。真正有意义的是先想清楚要不要用微服务，再思考要用哪种方法来实现，而无服务器只是实现方法之一。

InfoQ：哪些企业适合使用无服务架构，哪些又适合微服务架构？

Luca Mezzarila：首先，利用无服务器构建解决方案能帮初创企业快速部署生产环境。而大企业显然面临着更大的挑战，因为他们有大量的旧代码和旧逻辑需要处理，而当初编写这些代码、设计这些逻辑的人可能已经离职。因此他们需要先审视整个业务体系，然后思考该如何拆分这些代码和逻辑，从而让它们更容易被新人理解，下一步才是思考具体该使用哪种服务。所以有时候，采用混合架构也不错，毕竟系统中的某些部分可能跟容器匹配得更好，而某些部分更适合无服务器架构。

一切工作的本质都在于整合，而无服务器架构恰好是实现整合的出色方案。无服务器架构能用队列轻松消化掉流量，也可以用事件或使用 Amazon Lambda 函数来与其他系统同步。所以每当大家谈到边缘架构时，我想到的首选都肯定是无服务器架构。

另外我还发现，其实 API 并没有大家想象中那么脆弱。我们完全可以用 CDN 将流量转出源站，无服务器在这方面也有巨大优势，因为大家只需按实际用量付费。所以如果绝大多数流量都流经 CDN，那我们根本不用为所在区域的源站支付多少成本。

总之，想清楚自己的软件要表达什么是很重要的，这会为日后省下很多不必要的麻烦。

InfoQ：如果没有无服务器架构，编程工作会变得更复杂吗？

Luca Mezzarila：通常情况下，对于公司所掌握的每项服务、每段代码，我们天然希望它能对应一套连贯且统一的代码库。所以团队就得一同定义设计路径、确定所要使用的工具等等。但遗憾的是，这样的一致性总会随着时间的推移发生变化。对于开发人员来说，这就像是在戴着镣铐跳舞。所以，我认为基础设施的模块化表达可以在这里派上用场，我们只需根据业务稍做调整，而不必每次都重新做一遍配置。另外，从应用程序的整体性出发，我们会看到相似的情况总比特殊情况要多，而无服务器架构可以将这些相似的工作集成在架构中，减轻开发者的负担。

InfoQ：亚马逊云科技在推动向无服务器的全面转型方面做了哪些努力？

Luca Mezzarila：我们在亚马逊云科技建立了多个项目。我们面向的不只是开发者群体，同时也尝试改变企业高管层的思维方式，让他们了解包括无服务器在内，整个现代开发思维所带来的好处。除此之外，我们也有面向架构师和开发人员的项目，与他们一起走向现代化，也帮助他们了解如何构建事件驱动架构和微服务架构。我们也会与拥有无服务器经验的合作伙伴通力合作，甚至可以为客户推荐能帮其达成目标的合作伙伴。

我们为客户准备了很多充满潜力的选项。客户只需说明自己想达成怎样的目标，亚马逊云科技就能够提供相应的协助方案，而且大部分服务都是免费的。只要我们能在建模阶段把工作做到位，并在网站上发布丰富的说明文档、博文素材、应用实例，开发人员就能切实掌握值得借鉴的最佳实践。并且我们的努力涵盖各个领域，能帮助任何企业在云端取得成功。

InfoQ：亚马逊云科技自己的无服务器实践目前走到哪一步了？

Luca Mezzarila：无服务器技术在亚马逊云科技的内、外部工具中正在迅速普及。Amazon Lambda 函数的调用总量已达到 1 万亿。通过无服务器技术，我们部署了大量开箱即用的最佳实践，就连可用性保障都已经在函数部署过程中被默认内置，客户用不着为这些麻烦事分心。我们也在亚马逊云科技内部使用它支持客户、支撑自己的服务。

InfoQ：无服务架构在机器学习领域的前景如何？

Luca Mezzarila：现在已经出现了不少使用无服务器架构的示例，特别是在粘合各种系统的场景下。在我看来，最重要的就是用无服务器架构充当粘合剂，实现这些信息的跨系统传输，让开发者可以专注于真正重要的事情。

关于生成式 AI，我们在亚马逊云科技中已经成功落地。在开发层面，我们推出了 Amazon CodeWhisperer 插件，可以根据提示生成代码编写建议。另一项生成式 AI 服务是 Amazon Bedrock。它允许用户选择自己想要使用的大语言模型。我们还开发了自己的大语言模型，也就是 Amazon Titan。随着这些服务的推出，我坚信这种帮助客户灵活选择、定制大语言模型的方案一定能够大放异彩。

InfoQ：您对 AI 和无服务器之间的关系有何看法？二者有什么联系吗？

Luca Mezzarila：就目前来讲，我觉得只能算是有松散的联系。我们还需要进一步探索，毕竟大语言模型对内存容量有着极高的要求。尽管无服务器技术拥有自己的优势，但正如我之前提到的，它最大的优势应该是把不同的系统粘合起来，确保技术人员能专注于真正重要的工作。比如在 AI 语境下，你就可以专注于思考如何训练你的模型等等。同时，我很确定会有一些通过无服务器技术实现的有趣应用。社区那边就发布过不少方法，以新颖的生成式 AI 方法尝试简化开发者的工作体验。我有种感觉，其实很多工作正在幕后悄悄推进，只是我们还没看到。

InfoQ：您如何看待无服务器架构的未来发展趋势？

Luca Mezzarila：我觉得最重要的还是研究客户用例。过去几年间出现了大量关于无服务器的需求。亚马逊云科技推出的绝大多数功能都是应客户的要求而生。未来几年的重点应该是为无服务器重新找准定位，因为现在我们将其视作一种策略，而不只是简单的 Lambda 函数。

我们有些客户一直立足前沿，正在做一些我们从未预料的疯狂尝试。但同时也有很多客户要么对服务不完全信任，要么持明确的怀疑态度，还有一些客户并不太了解这项技术。所以我一直在努力为大家答疑解惑。我们建立了一套心智模型来帮助客户方的开发人员、架构师和平台团队把自己的软件以科学的方式映射到无服务器架构。这样，无服务器的负载就能快速增长，因为我们以往的观察已经证明无服务器架构具有诸多优势，令许多客户从中受益。

InfoQ：对于开发者来说，无服务器架构未来有哪些潜在的机会？

Luca Mezzarila：开发人员面前的机会有很多。他们可以编写出免维护的代码、建立更快的反馈循环，并开始研究如何帮助业务和产品所有者一同重塑业务。还有一个挑战是思维方式的转变。企业中仍然流行一种非常集中制的思维模式，单纯由组织顶层人员、或者说技术领导层来决定一切，而开发人员只是螺丝钉。他们没有机会与产品团队沟通，共同塑造成功的软件。产品和技术团队永远在彼此指责和争吵，我觉得必须要避免这种争执，让双方更好地合作，这才能给软件带来益处，进而惠及整个组织。

InfoQ：时代车轮滚滚向前，过去开发者可能更关注学习哪种语言、哪种新技术，但现在，特别是在疫情过去之后，企业开始更多关注利润。他们苦苦挣扎，要在糟糕的经济环境下生存下去。在这样的背景下，开发人员应该掌握哪些软技能呢？如何面对这样的大环境变化？

Luca Mezzarila：在组织中，“软技能”已经成为了核心技能。如果我们没有能力开展有效沟通、做出权衡，并代表企业的利益发言，即使你可以成为世界上最了不起的开发者，你也没法把握成功的脉搏。因为当今的现实是，我们写的每一行代码都不是为了娱乐自己而写，而是为我们的客户创造价值。

另外，开发人员现在需要身兼数职，他们工作中的开发占比越来越低，而需要对事物的发展变化具备更敏锐的感知。我建议大家不要局限于特定的框架或语言，而是着眼于更广泛的问题，包括架构、安全性、平台、基础设施等。这些会让我们成为更全面的开发者、更优秀的人才。还有一点要着重强调，当你以开发者身份做出一个超出自己能力的决定时，必须意识到这不只是一项技术决策，它也一定会在架构和组织层面产生相应的影响。

我发现很多开发者对分布式系统特别兴奋，或者每一种新语言都想去试试。但每一个框架都有自己的哲学、思维方式和合作生态。我觉得我们永远都要保持开放思维。你掌握了一种编程语言或框架，这当然是好事。但与此同时你需要看看你的周围，通过团队内不同成员的协同，我们才能构建真正有效的功能单元，在特定场景下大放光彩。我们要做 T 型人才，涉猎广泛的领域，并在特定的领域精通钻研下去，同时也有具备相应的软技能，从而在职业生涯中不断成长前进。