|
11 月 16 日，亚马逊副总裁兼 CTO Werner Vogels 发布了一篇名为《分布式计算宣言》的文案，为人们揭示 24 年前的亚马逊开发团队，是怎样在业务发展、架构迭代面对巨大阻力时，思考引入 SOA 架构和分布式思想，完成自我“革命”的。读罢令人感叹，每一个研发者都期盼得到成就感，去做一些真正有创造力的工作，做有些 24 年后仍然令 CTO 引以为豪，并转述给百万研发者的工作，而不是把时间和精力消耗在写千篇一律又没法复用的“胶水”代码，或是在越来越繁杂软件栈面前，疲于奔命地写业务流程并尽可能减少 Bug。
更加不堪的是，有时仅仅是由于同一项目的两个成员运用的库版本区别，咱们就不得不消耗海量的精力去处理冲突。当然，哪些成功的团队和研发者常常亦处理过一样的问题，但这种成就感的到来未免门槛过高。
不外，在太平洋时间 12 月 1 日的 re:Invent 大会上，Werner 展示了另一种可能 —— 一名研发者能够把精力放在更有价值的工作，而不必重复低效的劳动，在一系列 Serverless 工具的帮忙下，有些代码能够少写，由于将来你可能再亦不需要写它们了。倘若咱们抛开它们做为商场软件的盈利属性来看，这恐怕是自云原生理念普及败兴，最能好处研发者的制品发布。
自动化创建状态机和工作流，并彻底干掉“胶水”代码
对有限状态机最简单的理解是“if……else……”，但代入到负责开发场景里时，要实现有限状态机可不那样简单。
英国卫报是世界最大的英文媒介之一，在全世界持有几十万订阅用户，每周最少要为 60000 名用户准时送达订阅信息。不管支撑英国卫报的软件系统是怎样构建的，能够确定的是，这儿一度存在相当多的技术问题 —— 卫报的高级研发经理 Paul Brown 曾在采访中说到，卫报主数据库系统和所有第三方系统之间的数据流编排非常困难，且系统之间相互依赖，一个系统出问题就会产生连锁反应。怎样编排所有分布式系统，保准报纸的正确、即时交付，变成为了一个棘手问题。
马修国际旗下的一家子机构 SGK 遇到的则是另一个技术问题——她们要为甲方交付 ETL 管道，然则需要每日最少刷新两次输出数据，因此呢要跨多个数据库进行数据管理和复制；其交付数据的业务规则在持续更新；需要集成来自 10 多个区别数据源的输入数据。每一个数据源大概有 1–20K 行，85 列。怎样搭建 ETL 管道，又变成为了一个棘手问题。
这两种问题有一个共性，单纯用状态机做一个订阅流程或是 ETL 或许不难，但放在详细场景中则要思虑太多原因，且要承担系统守护的责任。Amazon Step Functions 最初诞生时，便是为认识决类似的问题，经过可视化拖动云服务的方式，构建事件驱动的工作流 —— 你当然能够选取从头 coding，但亦能够拖一拖搞定这个事。
为流式数据构建数据处理管道
这听起来很性感，但实质能支撑的并发工作繁杂有限，一次有效的最大并发数仅为 40，另一仅接受 JSON 数组做为输入源，整体还是比较受限的。这次re:Invent发布的 AmazonStepFunctionsDistributedMap 重点搞定了并发问题，从 40 提高到 10000，让 Step Functions 真正变得通用。下图为新老 Distributed Map 的有些关键数据对比：
表格作者：Sébastien Stormacq
在 Keynote 中，Werner Vogels 多次以“异步”、“事件驱动”等关键词来描述 Amazon Step Functions Distributed Map 的设计理念，但针对研发者来讲，可能更吸引的人是，倘若你已然会写 ETL ，那就能够少做有些重复工作，多去思虑有些能给业务、技术架构带来增量的开发工作。
除了烦人的业务流程外，另一个降低开发效率的工作是写“胶水”代码。所说“胶水”代码，便是指互不兼容的模块间（接口区别、语言区别等），需要写有些代码做连接才可正常工作。这类代码对业务无任何价值，纯粹是软件工程的副制品。
相信 Werner Vogels 和亚马逊云科技是看到了对这一问题的反馈，因此才发布了 Amazon EventBridge Pipes 这一制品 —— 它是 Amazon EventBridge 的一项新功能，供给针对生产者、消费者的点对点流程，自动完成模块集成，不需要编写“胶水”代码。
这个点对点流程的创建，需要重点思虑事件源、事件目的两个重点问题。
事件源发布时，Amazon EventBridge Pipes 支持以下服务做为事件源：Amazon DynamoDB、Amazon Kinesis、Amazon MSK 、Apache Kafka、Amazon SQS（标准和 FIFO）和 Amazon MQ（均用于 ActiveMQ 和 RabbitMQ）等。
事件目的则包含：AWS Lambda、Amazon API Gateway、Amazon SNS、Amazon SQS 和 AWS Step Functions 等。
尽管此刻在行业内的应用状况有待检验，但 Amazon Step Functions Distributed Map 和 Amazon EventBridge Pipes 实质传达了一种趋势：类似的服务在将来几年可能会越来越多，越来越成熟，告别低价值代码这件事是绝对可靠的，云原生时代研发者的技术栈需要做相应的调节。
倘若在将来，咱们能够不消处理经平常到的业务流程或 ETL 流程，亦不消写“胶水”代码，那将有海量的时间能够来思考业务、架构及流程本身的恰当性。
避免更糟糕的时间浪费
如本文开头所提，比起写一段 ETL 代码，或是写一段模块集成代码，更糟糕的是，将时间消耗在协作问题而非技术问题上。
这年头各企业的业务压力永远越来越大，需要能三天上线就不会拖到1星期，大部分时间里可能不会有工程设计这个概念，中间遇到的各样协作问题只能是“在起飞的过程中换轮胎”。
因此当 Werner Vogels 在这次 re:Invent 上发布 Amazon CodeCatalyst 时，台下的掌声非常热烈。
Amazon CodeCatalyst 的功能包含： 项目资源蓝图——不仅是新项目的脚手架，还包含支持软件交付和安排所需的资源统一研发环境，保持项目组环境一致管理 issue、pr、安排跟踪等CI/CD表示项目仪表板经过一封电子邮件就可邀请他人就项目进行协作统一搜索，跨用户、问题、代码和其他项目资源检索内容
这儿的资源蓝图包含起步代码、示例代码和云服务关联配置的最佳实践，其他几项亦都是软件开发项目管理的必需品。另一一大特殊在于 CodeCatalyst 本身集成的第三方工具是高度灵活的，是不是要用 GitHub 和 Jira，完全和团队的习惯相关。Werner Vogels 说，可视化是亚马逊云科技供给服务的一大特点，而大部分研发者应该亦认为可视化是个让人非常心安的标签。
Serverless 是所有构想的核心
回过头看，无论是 Amazon Step Functions Distributed Map 还是 Amazon EventBridge Pipes， 其核心始终是 Serverless，是 Lambda 这一制品本身。
Lambda 在 2014 年的发布，虽然展示了亚马逊云科技对 Serverless 愿景理念的深度洞察，但不可否认的是，当时的 Serverless 技术仍存在问题。直到这次 re:Invent，Serverless 的冷起步速度得到大幅优化，大数据核心制品全面 Serverless 化完成，才宣告 Serverless 技术发展的又一里程碑到来，云制品全面 Serverless 化只余时间问题。
而 Serverless 从技术、制品两个方面的成熟，亦直接为以上发布铺平了道路。试想倘若这些制品不是围绕 Serverless 技术来进行设计的，那样所有构想都将作为劫难 —— 没人能够忍受自动化创建业务流程的同期，还要关心服务器的配置问题。
这不只是在说 Serverless 技术好欠好用，亦是在说创新的门槛到底是高是低 —— 倘若你有了一个创意，Serverless 是最简洁的实现和验证手段，降低 Serverless 的运用门槛，便是在降低企业内的创新门槛。而亚马逊是一家尤其关注创新的企业，因此呢，Application Composer 应运而生。
Application Composer 的特点，在于能够帮忙生成安排就绪的项目，例如 IaC 定义文件和 Lambda 函数代码脚手架。
在传统研发工作里，配置 Serverless 服务需要理解 IaC （基本设备即代码）的概念，并写有些设备可读的定义文件。这个概念作进一步延展，就变成为了“基本设备可编程”，听起来是比较吓人的。
Application Composer 无疑大大降低了研发者内心对 Serverless 技术的畏惧程度，某种程度上亦便是加速了企业的创新速度 —— 当然，这亦需要企业充分理解云理念，并对云原生关联技术有相对成熟的运用经验。
3D 世界的构建正作为主流
在 Keynote 的末尾，抬头看路，Werner Vogels 给出一个大胆判断：将来 3D 会像视频同样普及。
去年，亚马逊发布拥有 3A 游戏研发能力的开源游戏引擎 Open 3D Engine（O3DE）。O3DE 的核心特殊是高度灵活的模块化功能，适合做 3A 级网游，完全免费，支持到位、更新简单。保准模块化功能的核心是带有源码和资源的 Gems 系统，不需要的功能能够完全不编译，极重提高了灵活性。
因此呢在发布后，O3DE 立即导致了热榜。
究其基本，O3DE 其实是亚马逊的 Lumberyard 的继承者，Lumberyard 引擎是 2016 年亚马逊与德国著名引擎技术研发商 Crytek 达成的一项交易，彼时深陷财务危险的 Crytek 以详细数字不详（传闻为 5000 万 -7500 万美元）的价格向亚马逊完整授权了 CryEngine 的所有代码，而 Lumberyard 便是 CryEngine 经过修改的免费版本。
到去年年底，开放 3D 基金会 (O3DF) 宣布推出 O3DE 的第1个稳定版本，这是一个 Apache2.0 许可的多平台 3D 引擎，可让研发人员构建 AAA 级游戏、用于视频制作的电影级 3D 世界，以及不受许可费或商场条款影响的非游戏运用案例模拟。
而这次 re:Invent 上的最后一个发布，亦与 3D 相关 —— Amazon SimSpace Weaver。Amazon SimSpace Weaver 是一种全新的完全托管仿真服务，可帮忙用户在云中安排大规模空间模拟。借助 SimSpace Weaver，用户能够创建拥有数百万个对象的无缝虚拟世界，这些对象能够实时相互交互，而无需管理后端基本设备。
结合去年发布的 Amazon IoT TwinMaker 来看，当下的 3D 技术脱胎于游戏，但已不止于游戏，以 SimSpace Weaver 为例，数百万个对象，已然对以智慧城市为典型的行业应用产生实质助推功效。
对智慧城市的建设仍然只是将来畅想的第1步，计算的将来在于对理学世界的极致模拟。当下的“绿色科技”，针对全世界都是一个挑战，那样应该怎样最有效地应用技术手段达成“碳中和”？量子计算或许是关键一环。Werner 以八年前他在夏威夷和 Terraformation 机构的讨论做为案例来解释这一问题。
大规模种植林木是实现“碳中和”的直接手段，但怎样有效经济地种植出一座森林，则是个繁杂问题。模拟仿真，能够让咱们这座森林将来的状态、规模、效用以及内部生态系统的变化有更知道的认知，但整体计算量将是恐怖的，量子计算机比经典计算机更适合这种仿真需要。
倘若将问题迁移到生命科学、材料科学，全面深入分子结构，计算量将以指数级增长，可能会快速超过行业的算力贮存，量子计算机的优良会变得更加显著。这亦是为何量子计算能作为当今学术科研的主流 —— 咱们能够经过量子计算机彻底迭代计算能力和模拟能力，而不是经过算法科研做有限的迭代和逼近。
Werner 在演讲的最后以量子计算为核心，展望了将理学世界数字化的可能与前景。他提及亚马逊云科技量子计算中心学者、世界知名的量子信息科学先驱名人 John Preskill 在 Youtube 已有许多优秀视频发布，阐述了利用量子计算来处理行业困难的思路和办法，并热情地举荐大众亦去认识认识。
这般看来，尽管量子计算如今仍处在科研的初期周期，但应用思路已然具备，前景是明朗的。从开发基本设备到 3D 仿真 ，再到量子计算，形成为了一条清晰明朗的将来科技演进之路。
这是这次 re:Invent 带给咱们的另一重惊喜。
与研发者一块构建将来
亚马逊云科技 Heroes 项目是社区最重要的构成部分之一，该项目表彰了全世界充满活力的亚马逊云科技专家群体，她们对知识分享的热情在社区中产生了真正的影响。
亚马逊云科技的 Heroes 能够以各样方式分享知识，包含经过社交媒介、博客文案、开源项目、视频和论坛进行在线分享，或亲自参加会议、研讨会和用户组活动。
这里次 re:Invent 2022 大会中，Heroes 的身影无处不在。Werner Vogels 博士亦在 Keynote 演讲中说到：“针对研发者而言，除了能够在亚马逊云科技为了帮忙研发者成长供给的 500+ 精心打造的课程中进行学习外，向你身边的技术专家请教亦会是一个很好的方式。”
亚马逊云科技今年亦重大发布了中国研发者官网，供给一站式平台，帮忙研发者学习成长及交流并链接全世界技术资源，助力研发者运用亚马逊云科技得到成功，与研发者一块构建将来。
在亚马逊云科技研发者社区官网，咱们发布了关于这次 re:Invent 更全面的信息新闻。
| 
发表于