AWS re:Invent 2020: Increasing innovation with serverless applications
[背景音乐] 大家好，我是David Richardson 过去几年来，我曾有幸登台 与我的朋友兼同事Deepak Singh一起分享 他是我们容器部门的负责人 然而今年有些不同寻常 无法与大家以及Deepak见面 我正在西雅图的工作室里，抱歉没法见面了 但为了充分发挥 今年re:Invent在线峰会的灵活性 我们决定通过两个单独的课程与大家分享 如果还没看过 我建议大家去看看Deepak的课程 我们知道，很多人会通过使用容器 和无服务器技术来构建应用程序 因此我将重点谈谈该如何进行创新 以及我们提供的这些功能是如何 帮助大家构建和重构应用程序的 Andy的主题演讲谈到了创新对 企业的重要性，并且还列举了几个 推动创新的重要因素 他谈到了速度对企业的重要性 以及企业为何需要通过更简化 并且更持续的方式解决客户遇到的问题 我也想强调这些 因为这些也是无服务器技术的重要指导原则 我们的目标是提供给用户创新的能力 让用户能以尽可能快的速度将产品投放市场 同时尽可能降低总成本 六年前我们发布了Lambda 至今荣幸地发现依然有那么多人在使用该服务 被成千上万客户构建的应用程序 每月上万亿次的调用 而Lambda依然以惊人的速度增长着 现在，Lambda成就了无服务器 而无服务器领域的英雄们所组建的民间社区 已然将无服务器技术变成 如何构建云的一场革命 我和我的团队很高兴看到无服务器社区 帮助新开发者和运维人员学习构建之法 因此在介绍新功能前，我想先对大家表示感谢 感谢整个社区所提供的各种反馈 我们发布的所有功能都受到了这些反馈的启发 我们也想听到大家新的反馈 以及对我们今年所取得成果的看法 那么客户为何要采用Lambda编程模型？ AWS有幸在云端应用程序构建的过程中 积累了数百上千年的工程经验 我们也从客户身上学到了很多 我们将所有这些经验融入自己的服务 从云中的构建工作中学习经验教训 我们从各种应用程序中总结共同之处 然后将其容纳到我们自己的服务中 这一切都是用完全透明的方式进行的 所以用户完全不需要考虑这些问题 就可以非常简单地上手并使用 我们在四个关键领域进行着不断的创新 借此提供简单而强大的功能 首先是帮助开发者和运维人员敏捷地快速前进 我们提供了大规模工作负载所需的性能 以及按用量付费的低成本服务 随后我们融入并持续改进服务的安全性 对这些领域进行投入 是因为我们认为这样可以帮助用户进行创新 首先谈谈如何通过创新提高大家的敏捷性 我们总是从事件驱动的架构着手 这是实现敏捷性的一种重要模式 Lambda最开始支持三种事件源 现在已经支持超过140种，外加EventBridge 对各类流行的SaaS集成的支持 对语言运行时的支持也有所扩展，最初 只支持少数几个，现在已经可以支持12个，同时可支持用户自带的语言扩展 我们继续投资AWS原生的可操作性能力， 包括CloudWatch和X-Ray 我们知道，很多用户希望能充分利用 其他开源工具 因此我们最近做了扩展 帮助大家使用第三方工具进行监视 就像使用AWS原生工具一样简单 此外我们还公布了开始支持将函数 打包为容器镜像 我们坚定地承诺提供更出色的监视 和运维能力 10月，我们还通过与 CloudWatch团队合作发布了Lambda Insights 同时也继续X-Ray和其他功能上的投入 但我们也知道，客户需要对所使用的各种类型的系统 进行管理，他更希望使用单一的商用 或开源栈同时对自己本地的和基于AWS的系统进行运维 而不希望混合运维 因此我们最近进行了扩展 借此大家可以更容易地使用惯用的第三方工具 监视并运维Lambda函数 Lambda扩展被设计为对目前 大家常用工具的支持 其配置和管理也非常简单 为用户提供了丰富的选项 我们可以使用管理控制台或CLI 您可以使用基础设施即代码 通过CloudFormation的支持 通过无服务器应用程序模型 通过Terraform或无服务器框架 甚至可以使用Stackery等服务来管理并配置他们 Lambda扩展能力包含两个组件 API的扩展，以及本身的扩展 API的扩展使得我们可以轻松构建工具 并在函数初始化、调用和关闭阶段 获得更多控制能力 很高兴有一批早期的作伙伴 已经在提供各种扩展 包括Epsagon、New Relic、Lumigo和Thundra 他们的扩展使得客户能够非常轻松地 直接使用自己的Lambda函数 API扩展则基于现有的Lambda运行时的API 可配合所有支持的以及自定义的运行时一起使用 并且任何人都可以使用 我们期待着合作伙伴与开源社区 甚至个人开发者都能借助扩展进行创新 让基于Lambda的应用程序运维更简单 我们知道，客户都希望通过一套 运维工具实现标准化，同理我们也知道 很多用户已经通过容器实现了这一点 利用容器对自己的应用程序软件进行打包 他们更希望使用同一套工具和培训流程 从自己的软件生命周期刚开始那一刻起 不断编辑、构建、测试并打包 因此我们提供了使用容器镜像定义并 打包Lambda函数的能力 而我们的目标很简单：希望客户 从容器工具方面的投入中获得全部收益 更轻松地构建并打包软件 同时更充分地享受Lambda在无服务器方面带来的完整收益 例如超过140种原生服务集成、Lambda简单编程模型 按用量计费的模式，以及自带的自动扩展能力 同时速度实现数量级程度的提升 并在容器编排系统中实现冷启动扩展 这并不象支持开放容器格式那么简单 除了发布对OCI镜像提供支持 我们还增加了对10GB包大小的支持 从而用户就可以使用大容器镜像 比如那些自带ML推论模型的镜像 我们还将标准镜像开源 这主要涉及我们所支持的语言运行时 当然也欢迎用户自行创建镜像或使用社区镜像 为了支持让用户自行创建镜像 我们开源了Lambda运行时的客户端接口 以及Lambda运行时模拟器的接口 大家可将其用于本地测试 例如配合Docker桌面或自己的CI/CD管道来使用 谈到扩展以及容器镜像支持情况的 另一个原因在于，我们对此真的感到很激动 整个团队已经为此辛苦工作了一年多 而我们迫不及待希望看到大家喜欢我们的成果 但更重要的，同时我们也认为很关键的一点是 要让Lambda的使用变得更简单 我们和大量客户进行了交流 尤其是已经在使用Lambda的客户 他们将其用于一些非常关键的应用程序 大家的一个共同反馈是 他们喜欢Lambda的简洁 以及极低的运维负担 但有时因为差异太大而需要很多额外工作 因此我们仔细思考了这些差异 怎样才能变得更有帮助，更有价值 例如事件集成以及近乎瞬时的自动扩展 但有时候这些差异仅仅就只是差异 并不能带来任何帮助 因此我们产生了开发扩展API的念头 借此Lambda可以直接得到整个生态的支持 例如丰富的运维工具，支持更广泛的容器镜像 这样的话，基于Lambda的开发和测试 才能更符合容器开发的要求 我们的目标是继续提供 Lambda在无服务器方面的所有好处 同时使其开发和运维更简单 并可以继续沿用现有的实践 现在如果你和任何一位AWS员工交流 他们很快就会开始分享 他们喜欢的客户故事 因为我们以创新的方式让客户用我们的服务 去构建他们的业务，和解决问题 可口可乐就是这样的客户，他们需要快速响应 COVID-19疫情带来的巨大变化 他们希望为饮料贩售机提供 零接触的客户体验 因此他们开发了一个全新的手机应用 可供客户直接下单购买饮料 而无需来亲自接触到售货机 由于使用Lambda构建，他们的团队 可以更专注于应用程序本身 而非安全、延迟或可扩展性 因为这些问题完全可由Lambda自己解决 最终他们在100天里就成功开发了这个新应用 现在超过30,000台售货机具备了零接触能力 使用Lambda和无服务器技术打造 应用范围如此广的应用程序，这让人感到惊叹 同时我们还在不断改善该服务的性能 以使其可以支持更多工作负载 今年上半年，我们发布了Elastic File System 附加存储卷的能力 这样，函数就可以更容易地处理海量数据集 并实现数据的持久存储 我们还希望进一步简化执行 大型计算作业，例如数据集处理作业的能力 因此我们已经将有关函数的计算能力提高到 10GB内存和6个CPU核心 我们还在努力降低冷启动 和热启动延迟，并提高并发性 这样每个函数即可用百万级甚至更高的TPS运行 如果你希望自行控制并发性 我们也提供并发预置 现在所有这些与性能有关的能力 都可用于Zip打包，以及容器打包的函数 我们还会继续在这方面进行改进 因为我们希望客户尽可能的更专注于 新应用程序的发布，而不会陷入困境 或者为了扩展而预先购置和构建 在他们不知道自己的应用程序需要多少资源的时候 当他们首次开始规划和预配置并发性功能时 这个功能曾引起广泛争议 团队中有一些人喜欢它，但也有一些人觉得 这不是无服务器技术，不能这样做 不过实际上，这都是为了尽可能简洁 我们还将继续努力降低冷启动延迟 并改善自动扩展能力，但我们知道有时候 客户对性能有一些非常具体的要求 他们比我们更懂，然而我们很遗憾地发现 那些顾客做了各种各样疯狂的间接升温功能 并不断跳转以努力实现他们的性能目标 我们认为，更好的方式是给他们提供一个开关 让他们实现他们所需的真实性能 我们只需要让客户简单地启用或禁用 或重新配置自己的函数即可 任何函数，无论是新函数，Zip定义的，或OCI定义的函数 这也可以让客户更容易地采用 让预配并发性成为我们增速最快的功能之一 安全性同样值得重视，安全性是Amazon的头等要务 我们的所有服务都已深度融入了安全特性 而我们的第一个目标是尽自己所能 在共担安全责任模式下承担尽可能多的责任 通过运维、补丁安装以及获得 一系列合规认证 我们在安全领域也进行了大量创新 尤其是在开源Hypervisor，Firecracker方面 对于Lambda，从一开始我们就希望 为虚拟机提供最强隔离边界 但考虑到容器敏捷性的要求，AWS开发了Firecracker 并将其开源，这样客户就可以深入检查 其安全保障，并让整个社区从中获益 但正如预配并发性那样 我们知道有些东西你肯定还是希望自己控制 因此我们还开发了非常明确的安全控制机制 提供了丰富的IAM功能 包括允许用户设置涵盖整个组织的安全护栏 在CloudFormation栈中预配置安全性 或使用CloudTrail、Config和GuardDuty 定义审计策略 如今我们在安全前端又提供了新功能 今年上半年，我们围绕无服务器技术更新了 AWS Well-Architected 指南 针对安全最佳实践提供了更完善的指导 以及运维和成本相关的最佳实践 随后还为Lambda函数提供了VPC访问控制 Lambda函数一直以来都可以 集成在VPC内部 在此基础上，用户可以强制设置 只允许从VPC访问Lambda函数 此外，我们还为AWS Lambda提供了代码签名 借此帮助客户全面控制 并治理自己的函数代码 我们还进一步增强了与AWS Signer和KMS的集成 并在降低成本方面持续进行着创新 对于多数应用程序，其大部分成本 实际产生于昂贵的工程开发时间 也就是构建和维护应用程序所需的时间 因此我们在这方面也不断创新 在帮助用户降低运维负担的同时加快应用上市速度 因为降低包括应用程序的支持和发布在内所需的 工作量有助于直接降低成本 对大多数用户来说，大型应用程序的 开发和运维往往“贡献”了最大比例的TCO 我们还在基础架构方面进行着创新 借此进一步降低单位成本 首先是内置的自动扩展功能以及按使用模型付费 所有无服务器产品都可获得这些功能 多数企业不断努力才能实现10%的利用率提升 即使运维状况最佳的应用程序最高可只能获得20%利用率的提升 很多文章都谈到了这一点 但关于利用率，最有趣的地方在于，大部分人 高估了自己的做法 同时也低估了提升利用率的难度 我于2006年加入AWS，我得承认 幸亏面试的时候没人问过我有关利用率的问题 因为我当时的想法完全是错误的 我觉得，如果当时有人问我这类问题 我可能会猜服务器利用率能达到50%左右 差不多就是翻一倍应对峰值负载的水平 如果实现不了，顶多简单调整一下软件 就能实现这样的水平，但在加入团队后没多久 我意识到当时的想法有多离谱 过去大概十年来 我几乎每周都在查看我们的利用率水平 提高利用率需要对整个栈进行大量调整 我们与硬件合作伙伴一起优化SSD frameware 调整性能和存储的配比 以满足工作负载的需求 为了更好地在所有服务之间实现平衡 我们在供应链上缩短交付周期并调优Java 和其他语言运行时，以降低垃圾回收开销 我们还在数据科学方面大量投入去研发算法 和ML模型，以便更合理地放置工作负载 借此我们可以在提高利用率的同时 改善可用性，并减少性能抖动 最终我们成功地 将利用率提升了好几成 这是我们做过的最难的工作之一 我得承认，这事其实还挺有趣的 因为我们需要与不同专业的人广泛合作才能 实现如此程度的改进。而我们的目标之一正是 通过这样持续不断的努力工作 提高服务器利用率，并让用户从中获益 正因为如此，为了让用户 在不断提高的服务器利用率中获益 我们减小Lambda的计费粒度 从原本每100毫秒为计费单位降低至每1毫秒 有些函数，借此可将成本降低高达70% 例如短时间运行的函数 就是那些主要负责处理人机交互的工作负载 我们知道，敏捷可以让我们改变心态 因此我们将Lambda加入了Compute Savings Plans 我们希望客户能够灵活地 用不同实例、容器和函数 更改自己的计算架构，而无需 冒险打破自己有关Savings plans的财务承诺 Savings Plans可以为用户所用的全部计算资源 自动提供力度最大的折扣价格 由于架构不同，成本也很难进行对比 用户通常只能进行猜测 很多时候这种猜测难以控制或者不够客观 对于无服务器，我们尽可能让他简单 通过针对每条消息、每个请求或计算资源的用量来计费的方式。 我们在这些价格中加入了自动伸缩、 负载平衡和容错功能， 这些功能在传统架构中必须独立构建、运行和支付。 因此在考虑替代方案时，请务必考虑所有这些成本 并且考虑利用率时，请以毫秒为单位，而非以天或周为单位 总的来说，对所有这些与计费方式以及敏捷性 有关的改进，我们的目标在于帮大家快速上市 同时尽可能降低总体拥有成本 我们已经介绍了客户采用无服务器，以及 我们在该领域不断创新的主要原因 这一切的重点都在于敏捷性 我们希望保持敏捷以便快速前进 借此响应并适应变化 这样的能力在今年比以往更为重要 回想去年的re:Invent吧，如果当时你也在场 我敢说任何人都不可能猜到峰会结束后的 几周时间里会发生什么 谈到无服务器技术和响应变化的能力 让我们一起欢迎来自Capital One的Lavanya 她将分享她们是如何应对 疫情带来的独特挑战 谢谢David，大家好 很高兴能通过今天的活动谈谈 Capital One是如何 利用无服务器技术实现联络中心的 我负责Auto Finance Division部门的 业务服务线技术，我们的目标是确保 让客户的乘车和驾驶体验更舒适 设计联络中心时，我们的首要目标是 确保能轻松扩展以处理大量语音流量 并保证整个系统是模块化的，足够灵活 以便添加新功能，并能及时投放市场 因此在设计呼叫中心的架构时 我们选择以Amazon Connect为核心 当客户来电与交互式语音响应系统 进行沟通时 或当客户直接致电时，该通话 首先会转向语音服务提供商 随后被路由至Amazon Connect 此时，我们有多个Lambda函数来设置调用通话的上下文 381 00:19:11,900 --> 00:19:15,823 以获取客户帐户详细信息 以及队列和代理详细信息 这样就能让合适的代表与对应的客户建立联系 简而言之，我们用Lambda函数编排通话流程 通话结束后，我们还会借助Lambda函数 执行下一步流程，例如生成通话录音文本 以及通话追踪等 基于我们去年实施的这个架构 我们可以轻松处理海量通话 并实现极高的服务级别 然而直到今年，COVID疫情爆发 全球所有地区所有人都开始面临剧变 隔离在家，失业，找不到工作 我们需要解决很多挑战 因为生活已经发生了彻底的改变 与此同时，我们的呼叫中心 话务量开始出现激增 不仅如此，我们的人手也几乎减半 处在艰难情况下的客户 急切地希望与我们通话，一遍一遍打电话过来 这导致通话的排队等待时间一度接近4小时 这对我们的服务级别也产生了不利影响 我们明白，应该做些什么了 应该非常非常快速地做出一些改变 我们是怎么做的？ 无服务器技术帮助我们专注于核心需求 而无需担心基础架构扩展问题 我们主要专注于两件事 首先，尽可能快地让我们的客户代表实现在家办公 这样才能获得足够的人手 此外我们重点实现了一些新功能，例如回拨、队列深度 通话等待时间，以及自助服务功能 这样就可以将一些客户来电转至自助服务 在老架构中，如果要实现这一切 可能需要花费数周，甚至数月时间 但在新架构中，我们从3月15日开始 到3月底就完成了所有工作 4月1日，我们的话务量依然很高 但服务级别已经恢复了正常水平 人手方面也提高了85% 通话等待时间由之前的4小时 缩短至不到10分钟，这对我们的客户起到了莫大的帮助 借此我们可以在客户最需要的时候 在恰当的时间提供客户需要的服务 当客户丢掉了自己的工作 在当时那样艰难的时刻向我们倾诉时 作为一家以人文关怀为中心的公司 我们真的非常关心 我们知道自己正在为客户们做出正确的事情 这是技术人员的高光时刻 因为我们知道，我们设计了一流的系统架构 可以经受住时间的考验 谢谢大家 谢谢Lavanya 很高兴无服务器技术可以帮助你们 为你们的客户提供如此多的好处 听到客户通过无服务器技术构建各类应用，我们总是很激动 今年，我们一直在反复思考一件事 客户除了构建不同的应用程序 又是如何采用无服务器技术作为自己 多种应用程序的核心构建模块的？ 具体的采用过程是什么样的？ 我们和大量客户进行了交流 来更好的了解他接受无服务器技术的整个过程 这帮助我们意识到，自己需要构建类似Lambda扩展 以及Lambda容器镜像之类的功能特性 因为我们觉得应该进一步简化无服务器的采用过程 这需要兼容现有工具 但对于开始构建新应用程序的客户 这个过程具体又是怎样的？ 初创公司是一个很好的例子 他们需要构建各种新应用 例如Stedi构建了商业贸易网络 借此在B2B交易中自动实现数十亿美元的转账 他们做到这些是通过无服务器为先的策略 借此业务无论发展到何种规模都可顺利应对 正如Zack提到的，他们选择无服务器技术是为了将运维负担降至最低 也为了能轻松扩展至任何规模 无服务器为先，这种战略思路已经 被我们很多已经获得成功的客户所采用 他们面对挑战，基于无服务器技术 构建了各类全新应用程序，这一点很重要 因为不断扩展的构建工作很难，实际上 无论作为初创公司或老牌企业，几乎不可能 知道第一版是否能实现目标并 向数百万客户提供服务 或者能够覆盖更多受众 如在第一版就部署极为巨大的规模 和提供极高的性能，这其实非常难 对于传统架构而言，这需要付出大量时间 我敢说，这是我们团队在Amazon内部曾经 做过与产品有关的最艰难的决策 关于创新，我们学到了一件事 那就是真正帮助客户的最佳方法是 发布并迭代。正如Andy提到的，速度很重要 但对于每代产品，我们还需要预测增长速度到底可以有多快 我们必须在发布前就针对这样的增长速度做好准备 如果预测过高，等于浪费了时间、和昂贵的工程 资源及基础架构，这些东西本可用于下次迭代 但如果预测过低，那么无疑也会遇到问题 可能需要长时间的通宵赶工才能解决 因此我们将大量精力投注于无服务器可扩展性 借此实现的快速扩展能力和高可用性 甚至会让大部分客户感到吃惊 我们的目标是让用户专注于业务逻辑 而AWS专注于扩展和可用性 现在我们终于领先于最初的目标 我所提到的无服务器为先策略 有助于我们的客户获得最佳的营销时间 和TCO收益，但很多客户并未这样做 我们经常看到客户总是先经历 采用的三个不同阶段 他们通常会从IT自动化着手 例如使用Lambda函数验证一些配置 每次都要启动一个EC2实例 接下来个别团队可能会开始将Lambda与 S3或Kinesis Streams集成 来构建数据处理应用程序 随着更多团队掌握了相关经验 客户才开始构建基于微服务的应用程序 采用过程的所有这些阶段还有一个共同之处 大家会遵循互联网和Web的设计理念 让大量小部件松散地结合在一起 所有应用程序都是一个个模块 由多个AWS服务和客户自己开发的组件构成 这就是为什么我们如此重视交付大量 将Lambda和EventBridge和API Gateway以及和Step Functions的集成能力 我们希望简化构建新应用程序 和功能性，通过松耦合 用其他AWS服务和用户自己的组件来实现。 这通常从API Gateway管理API开始 API Gateway可以看作是应用程序的前门 而事件或消息是位于后端的通信系统 对各种工作流进行协调 这种架构的另一个常见要素是 它们都是事件驱动的 我将其看作一种回到未来的设计模式 类似于八九十年代的企业消息总线模式 那种事件驱动的架构在今天依然适用 因为这是实现敏捷性的理想方式 可以促进松耦合，是一种自然的模式 方便一个系统对其他系统中的变化做出回应 并为新能力的构建提供特别棒的支持 同时可支持现有系统的重构 这就是为什么客户们通常会从IT自动化着手 随着事件对业务产生影响 或者对IT基础架构产生影响，你可以自动回应 客户通常还会从IT自动化转向 数据转换型工作负载 Lambda的一个重要好处在于 可以用近乎实时的方式做出响应 随着客户创建更多数据流 无服务器处理数据的方式将变得极具吸引力 Nielsen Marketing Cloud就是这样做的 并且在一个极大的规模下。 他们使用Lambda每天处理2500亿条事件 同时保持了高质量、高性能和低成本 这都是通过完全自动化的无服务器管道实现的 他们系统的规模非常大 这也是选择采用Lambda的原因 业务峰值时，Nielsen每天会收到55TB数据 处理这些数据需要调用Lambda函数300万次 然而整个系统的运行完全没有任何问题 甚至可扩展至3000个并发Lambda 相比一个普通日 那时他们只收到1-5TB数据 这些都可以自动扩展. 自动扩展的整个过程都 无需值班工程师介入并执行任何操作 现在Nielsen还将数据传给广告业务合作伙伴 随着进一步提高整个系统的规模 他们发现自己的广告合作伙伴很难跟上节奏 于是他们构建了一些用于限制速率的Lambda 这些Lambda可根据文件大小、速率、请求量 等因素帮助合作伙伴处理数据 其实Kinesis和DynamoDB Streams的处理 是我们最受欢迎的工作负载 我们希望进一步简化这些工作负载 因此在过去几年，我们添加了额外的支持 借此简化处理流的工作， 例如Auto-Sharding 现在我们还开始支持处理不同时间窗口内的流聚合 借此即可执行各种运维 例如计数、求最大/最小/平均值、求总和 最后，越来越多组织逐渐开始采用 无服务器架构作为核心应用程序设计模式 这通常看起来像是让Lambda作为核心计算服务 借此实现模块化或微服务架构 这其中可能有各种类型的应用程序 从Web和移动后端到HPC，甚至是财务模拟 不得不承认，这确实让人吃惊 我当时在使用AWS另一个低级别的服务 当Lambda发布后，我立刻就 发现Lambda很适合用于实现IT自动化 以及数据转换型工作负载 但我总觉得它还可以做更多 我不清楚它的应用范围能有多广泛 哦，这样说也不对 我们的很多客户已经亲自证明了 他们可以利用Lambda构建整个应用程序 甚至在我意识到能这样做之前他们就早已做到了 我觉得我的失误在于自己并没有意识到 Lambda事件驱动的能力到底能有多强大 以及用它解决棘手业务问题的过程能有多简单 事件驱动的架构，感觉上类似于，怎么说呢…… 因为我知道，Amazon.com的很多核心系统 就是使用事件驱动模式构建的 那些系统都是很重要的应用程序 并且需要快速增长，快速改变 来满足Amazon.com飞速变化的业务需求 回想一下，我觉得我实际上太专注于 自己所负责的传统架构 因此有时我们会为如何谈到这些模式而争论 是该称之为反应式应用程序 还是应该将其看作触发器，甚至无服务器微服务？ 这类讨论通常可能都是我发起的 因为我总担心别人有时候也会有类似反应 我首次称之为事件驱动， 我们不希望人们认为， “这些模式也许只适用于很少的用例” 我们希望大家能够相信 借助Lambda可以满足各种工作负载需要 但实际上我们只需要信任我们的客户 他们已经发现 事件驱动架构不仅强大而且简单 同时它们是构建各类应用程序的一种自然方法 因此BBC这样的客户用这种方法构建了他们的网站 直到最近BBC大部分网站都是用PHP开发的 同时被托管在伦敦周边的两个数据中心内 网站上线时间是2010年，那时这是很常见的做法 但时过境迁，BBC重建了自己的整个网站 借此提高灵活性、可扩展性和速度 他们用一种现代的模块化架构来实现 并采用了无服务器策略 他们将全过程写成了一篇博客文章 建议大家都能读一读 从另外的角度来举一个例子 他们有将近2000个Lambda函数 这些函数每秒都要为BBC的网站渲染网页 预计该数量还会增长，BBC选择了Lambda 来降低他们的运行和维护成本 并改善其扩展性 当遇到突发新闻事件，网站流量激增时 Lambda可以快速扩展轻松应对 这很常见，现代云应用程序 由许多服务和组件组成， 当应用程序增长， 需要编写很多代码来协调 所有组件之间的交互 我不能说AWS内部投入了多少工程力量 来实现诸如重试逻辑、回退算法 和接收队列进行调优 这是托管工作流有优势的地方 他们可以让你专注于定义组件之间的交互 更多在逻辑层面上进行，而非编写各类软件 仅仅去为了让交互能够生效 Step Functions是我们的无服务器云规模工作流服务 与其他所有无服务器产品类似 它具备丰富的集成能力，能配合其他服务使用 我们还继续对其扩展，使其支持更多工作负载 最初，Step Functions只针对持久的 长时间运行工作流优化 最多可支持连续运行一整年的工作流 去年，我们发布了Express Workflows 该服务针对低延迟、大容量、低成本的 异步工作流优化 今年，自然而然地，我们再一次扩展 提供了Synchronous Express Workflows 该服务同样针对大容量用例优化 但可以像人工交互工作负载那样实现同步 却维持了与异步工作流类似的低成本 作为构建新应用程序的方式， 无服务器的意义可见一斑。 但很少有应用程序是全新的， 更多时候，客户都在忙于对现有工作负载进行重构 可能是为了跟上规模需求，或交付新功能 总的来看，我们的客户有了多种选择 首先，最好的办法是减少或淘汰那些你现在直接负责的不必要的东西， 并且在不同位置采用SaaS 其次，进行一些平移，迁移到AWS 大部分客户这样做即可快速获益 通过一个通用平台管理数据中心 接着是现代化革新，我们讨论了重新设计平台 实际是指，需要将自行管理的服务 迁移为AWS代管的服务 例如从自管理的数据库迁移至RDS 或从自管理的Rabbit MQ改为Amazon MQ 最后，我们的客户往往将 重构看作是最大的转型手段 获得成功的客户往往最开始会选择对自己 最关键，或面向客户的应用程序进行重构 这样才能充分获得加快上市速度和TCO等收益 这是从较高层面的探讨 具体细节，我想邀请 Vishal分享Discovery Golf如何通过重构实现现代化 大家好，我是Vishal Parikh 我在Discovery Golf担任产品主管 今天，很高兴能和大家分享 我们重构为无服务器架构的体验 Discovery是一家全球领先的传媒公司 提供了覆盖不同领域的大量内容 我们通过90多个品牌提供娱乐和体育内容 一些品牌你可能已经很熟了，包括 Discovery Channel、Food Network以及HGTV Discovery已经将工作中心转向 直面消费者的行业，并为此进行了巨大的投入 这意味着客户体验始终是我们最关心的 Discovery旗下的Discovery Golf包括 由PGA Tour和Golf Digest带领的Golf TV Golf TV是一种流媒体服务，主要直播PGA 锦标赛、欧洲巡回赛以及其他主要赛事视频 全球各大洲都可以看到我们的节目 我们有着宏远的计划，Golf TV 流媒体平台仅四个月就开发构建完成，并于2019年1月上线 随后我们的平台实现了快速增长 包括全新来源的内容和数据等 该平台的构建是由一家公司 使用专有的数字化生态 包括前端应用程序 和后端系统以及相互之间的集成 虽然当时很好用，但随着业务增长 我们开始遇到挑战，因为一切对我们来说都如同黑匣子 我们完全无法控制用户体验 无法足够快速地解决客户遇到的问题 无法添加功能和特性 进而无法容易地满足业务需求的增长 我们需要能够自行控制一切 并且希望首先从用户体验开始 Golf TV遇到了一些独特挑战 我们会在非预期时段收到来自不同区域的峰值流量 周末的高尔夫锦标赛期间出现峰值不足为奇 对我们来说，全球不同地区的峰值情况更严重 例如，当Hideki Matsuyama在大师赛中取得好成绩后 我们立即发现大量来自日本的流量抵达平台 我们需要一种自适应的环境和基础架构 来支持快速、非预期的变化 我们还需要数据聚合能力 聚合不同来源的数据，例如巡回赛合作伙伴， 内容管理系统、来自不同巡回赛合作伙伴的直播数据， 调度和广播信息，以及 Golf Digest的文章和编辑专栏数据。 我们将所有这些都集成到了自己的用户管理 和订阅管理平台 借此驱动对我们用户来说非常关键的功能 我们希望以一种使我们 能够连接回遗留系统的方式来构建系统 以便继续利用原有的后端技术 最终我们选择重构为无服务器架构 因为我们知道，自己团队规模不大 我们希望更专注于用户体验 因此需要更侧重于核心产品、 而不是考虑扩展、预配以及 可用性等问题 我们还希望逐渐开始 构建无服务器中间件，借此使得我们能够 在未来更改后端基础架构和系统 对我们来说，这一切始于一个决策 采用React Native前端框架，于是我们 在无服务器端使用了AppSync 因为它支持GraphQL API 随后我们将AppSync连接至Lambda 后者负责从不同数据源 获取数据 包括DynamoDB ElastiCache以及第三方内容和元数据 Lambda还支持direct Lambda resolvers, 借此我们可以容易地在AWS上将Lambda与GraphQL配合使用 这一切结果如何？ 我们新系统的构建和集成速度提高了40%, 预计的云成本降低了15%以上 工程方面的成本可节约 12%-20% 相比其他备选方法，这种构建方式 无疑更适合我们 对我们来说，更值得高兴的是 可以更快速、简单地响应客户需求 包括让用户更轻松、快捷地观看直播内容 并在直播的同时提供实时积分榜数据 放眼未来，我们高兴地看到无服务器为先策略 帮助我们获得了面向未来的灵活性 因为未来一切都有可能 通过将前端和后端系统解耦 我们可以更充分地利用Discovery现有的全球技术平台 而无需反复重建前端 这意味着当机会出现时，我们可以快速成长和适应 根据业务需求灵活应变 例如，我们可以自动向上扩展 以应对突发流量峰值，快速使用新的数据源 甚至通过新功能快速开拓新的收入来源 我们对于自己选择的这条路很满意 随着工程开发速度的继续加快 相比非无服务器的方法，云成本以及 实现相关技术所需的成本都显著降低 更棒的是，我们才刚刚开始 我们针对Golf TV业务所做的技术决策 可以帮助我们探索新业务线和收入来源，例如 旅游之类的，因为无服务器策略 使得我们能够轻松连接新数据源 针对各种情况快速回应 最终，我们可以将Golf TV学到的经验 应用到其他业务领域，并更大范围的 节约成本，改善可扩展性 谢谢 谢谢Vishal Vishal提到了Discovery Golf 如何对一个应用程序进行重构 同时让技术平台上的其他组件继续保持连接 我们发现这种集成方面的挑战是我们的客户 最常见的问题之一，因此我们会继续投入 让集成过程变得更简单 我们的很多云原生和云托管产品 都有助于将现有技术栈连接到云 我们还会继续让这个过程进一步简化 最近新增的功能包括Amazon MQ 已支持Rabbit以及Apache ActiveMQ 大家还可通过Amazon MQ触发Lambda函数 借此更容易地构建无服务器应用程序 我们还考虑增强Lambda与 Amazon托管的Kafka或MSK之间的集成 去年，EventBridge增加了 对流行SaaS合作伙伴提供事件的支持， 同时还增加了对AWS和自定义事件的支持。 API Gateway长期以来一直支持通过直接连接 将AWS服务和您现有的本地平台集成。 对于需要托管工作流的客户 我们发布了Amazon Managed Workflows for Apache Airflow 并且在re:Invent之前刚刚发布了对 Amazon Managed Workflows for Apache Airflow的支持 客户们喜欢Airflow Workflows 因为它有着活跃的开源社区 通过丰富的库提供了到第三方数据的预置集成 还提供了丰富的处理工具，以及使用 Python脚本创建工作流的能力 对于Manage Workflows for Apache Airflow 我们可以顺利应对运维和管理挑战 让数据工程师和开发者团队 专注于研究和开发 我们讨论了创新的业务需要的能力 它帮助我们更快速地前进 更简单地构建，更快速地面向客户交付 AWS非常关注开发者 我们认为开发者和运维人员 都是无服务器为先策略最重要的构建者 我们的很多新功能，例如Lambda扩展和VPC 访问控制最初都是针对云运维人员构建的 因为很多时候往往是运维人员先采用Lambda 这是因为Lambda可以大幅简化 IT自动化相关的工作 此外诸如更大的Lambda函数 和Synchronous Express Workflows等功能 也可以帮助开发者更快速地构建 随着客户上云，角色可能发生变化 我们的目标是通过构建功能帮助运维和开发者 在自己负责的相关工作中获得成功 我感觉运维人员和开发者之间的 协作很有趣，他们如何通过合作构建 并运维现代化云原生应用程序？ 有一种日益普及的协作模式 就是云卓越中心，也叫做云平台 或共享的服务平台，叫法各不相同 运维人员希望分享最佳实践 和强制实施安全策略 他们的运维工具足够高效和标准 但这并不会限制开发者的自由和敏捷性 其中一个核心工具就是是基础架构即代码 该工具可以让运维人员将最佳实践 和策略记录到模板中 容器映像在这种协作中也可以很好地工作， 因为它们完全封装了应用程序代码， 并且可以使用像Elastic Container Registry这样的工具来管理它们， 并且很容易被推理代码引用 为此我们开发了Lambda Extensions和Lambda 容器镜像，来支持开发运维人员的此类协作 我们还通过CloudFormation和SAM为 基础架构即代码提供所需的支持 正确的运维和开发者工作流程很重要 如果能正确构建，就可以轻松地应用有关安全 和治理功能，并分享最佳实践 若不具备，开发者将只能独立完成相关工作 如果出错，那么将重回古老的集中化IT 并处处受限，无法从中获得速度和敏捷 也就是为什么容器和无服务器团队还开发了Proton 这是首个完全托管的部署服务 适用于容器和无服务器应用程序 我们希望运维人员和开发者 轻松协作 来帮助中央基础架构团队 定义架构模板，我们称之为栈 并在其中融入所有最佳实践 运维工具，以及安全策略 随后将其提供给开发者使用 开发者可通过容器和Lambda函数加入自己的业务逻辑 并借助Proton与CI/CD pipeline的集成 将应用程序和变更发布到生产环境 它配置所有的管道和监视 而无需开发者自行配置 底层AWS资源和依赖关系 Proton可以帮助开发者轻松地部署代码 并确保一切符合架构和安全标准 同时开发者依然可以快速前进 它的工作方式是，中央基础设施团队在Proton中构建栈， 定义供应所需的一切， 并部署和监视他们的应用程序组件 随后当开发者准备好部署后 即可从Proton中选择所需的栈 将其连接到GitHub等代码存储库 Proton可以自动预配所有基础架构资源 配置CI/CD pipeline 和监视工具 并将代码部署到新的基础架构 这一切完全无需开发者配置 底层的AWS资源或依赖关系 Proton可以处理这些工作并将其抽象出来 基础架构团队还可以在Proton中更新栈 Proton可以找出所有非最新状态的部署 使团队可以轻松地集中推送更新 这也填补了目前基础架构和代码部署 以及管理方式中的一个缺口 一些人认为这是一环绕一环的“海龟” 我更愿意认为这是一环套一环的“烤奶酪” 实际上，这些是一环套一环的创新 我们的目标是帮助客户创新 而无服务器技术可以帮助用户加快上市速度 当考虑在哪里创新，以及如何创新时 我们会考虑从哪里着手最有助于创新 我们认为无服务器技术提供了最必要的敏捷性 借助新的Lambda扩展和对OCI的支持 提供了可满足不同工作负载需求的性能 现在通过扩展可支持10GB的函数、预配置、并发 以及自动扩展，提供比其他任容器编排系统更快的速度 也可通过每一毫秒作为计费单位，并借助 灵活的Savings plans获得更低TCO 同时可以支持松连接系统 它提供了140种集成 并能与SaaS以及现有技术栈 进行集成 感谢成千上万客户的故事 带给我们的启发 他们使用无服务器技术进行构建 尤其是要感谢Capital One、Coke Stedi、Nielsen Marketing Cloud、BBC以及Discovery等客户 今天登台分享自己的故事 我们刚刚发布了一系列新功能 并迫切希望看到大家如何使用它们，进而带给我们更多启发 别犹豫，立即上手，用这些新功能开始构建吧！ [背景音乐]
2021-02-13 11:33
