从今天起真正释放创造力 | Werner Vogels 在 re:Invent 2022带来多项开发者福音

亚马逊云开发者

于 2022-12-02 22:03:02 发布

阅读量225

点赞数

文章标签： java 开发语言

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg4NjU5NDUxNg==&mid=2247531830&idx=1&sn=b48d616be35222b8966b03d94855cad7&chksm=cf95738df8e2fa9b855ec93967b5717688b24c9dc5a0895df7629d09efdcb34f51a4687d2304&scene=126&&sessionid=0

版权

点击上方【凌云驭势重塑未来】

一起共赴年度科技盛宴！

对于开发者而言，成就感来自于每一次敲下代码后可实现的创造力，而不是把时间和精力消耗在写千篇一律又无法复用的“胶水”代码，或是在越来越复杂的软件栈面前，疲惫地写业务流程并尽量减少 Bug。

更加不堪的是，有时仅仅是因为同一项目的两个成员使用的库版本不同，我们就不得不消耗大量的精力去解决冲突。

不过，在太平洋时间12月1日的2022亚马逊云科技 re:Invent 全球大会上，Amazon.com 副总裁兼首席技术官 Werner Vogels 博士向开发者们展示了另一种可能——把精力放在更有价值的工作，而不必重复低效劳动。在一系列 Serverless 工具的帮助下，一些代码可以少写，因为未来你可能再也不需要写它们了。这恐怕是自云原生理念普及以来，最利于开发者的产品发布。

自动化创建状态机和工作流

和“胶水”代码挥手作别

在 re:Invent 2022大会的主题演讲中，Werner Vogels 博士多次以“异步”、“事件驱动”等关键词来描述 Amazon Step Functions Distributed Map 的设计理念。但对于开发者来说，可能更有吸引力的是，如果你会写 ETL，就可以少做一些重复工作，留出更多时间去思考能给业务价值、技术架构带来增量的研发工作。

除了恼人的业务流程外，另一类降低研发效率的工作是写“胶水”代码。所谓“胶水”代码，就是互不兼容的模块间（接口不同、语言不同等），需要写一些代码做连接才能正常工作。这类代码对业务没有任何价值，纯粹是软件研发过程中的副产物。

它是 Amazon EventBridge 的一项新功能，提供针对生产者、消费者的点对点流程，自动完成模块集成，不需要编写“胶水”代码。

——Werner Vogels 博士

Amazon.com 副总裁兼首席技术官

这个点对点流程的创建，聚焦在事件源、事件目标两个主要问题上。

事件源发布时，Amazon EventBridge Pipes 支持以下服务作为事件源：Amazon DynamoDB, Amazon Kinesis, Amazon MSK, Apache Kafka, Amazon SQS (标准和 FIFO) 和 Amazon MQ (包含 ActiveMQ 和 RabbitMQ) 等。

事件目标则包括：

Amazon Lambda, Amazon API Gateway, Amazon SNS, Amazon SQS 和 Amazon Step Functions 等。

Amazon Step Functions Distributed Map 和 Amazon EventBridge Pipes 的发布实际传达了一种趋势：类似的服务在未来几年可能会越来越多、越来越成熟，告别低价值代码是大势所趋——云原生时代开发者的技术栈需要做出调整。

如果在未来，可以在常见的业务流程或 ETL 流程上少花些时间，也不用再写“胶水”代码，我们就会有大量时间来思考业务、架构和流程本身的合理性。

避免更糟糕的时间浪费

当然，比起写一段 ETL 代码或是写一段模块集成代码，更糟糕的可能是将时间消耗在协作问题而非技术问题上。

随着业务压力的不断增加，需求能三天上线就不会拖到一周。开发者的大部分工作时间中可能都不会有工程设计的概念，中间遇到的各种协作问题只能是“在起飞的过程中换轮胎”。

所以当 Werner Vogels 博士在这次 re:Invent 2022上发布 Amazon CodeCatalyst 时，台下开发者的掌声十分热烈。

Amazon CodeCatalyst 的功能包括：

项目资源蓝图——不仅是新项目的脚手架，还包括支持软件交付和部署所需的资源
统一开发环境，保持项目组环境一致
管理 issue、pr、部署跟踪等
CI/CD
显示项目仪表板
通过一封电子邮件即可邀请他人就项目进行协作
统一搜索，跨用户、问题、代码和其他项目资源检索内容

这里的资源蓝图包括启动代码、示例代码和云服务相关配置的最佳实践，其他几项也都是软件研发项目管理的必需品。另外一大特色在于 CodeCatalyst 本身集成的第三方工具是高度灵活的，是不是要用 GitHub 和 Jira，完全和团队的习惯有关。

可视化是亚马逊云科技提供服务的一大特点，而大部分开发者应该也认为可视化是个让人十分心安的标签。

——Werner Vogels 博士

Amazon.com 副总裁兼首席技术官

Serverless 是所有构想的核心

回过头看，无论是 Amazon Step Functions Distributed Map 还是 Amazon EventBridge Pipes，其核心始终是 Serverless，是 Lambda 这一产品本身。

Lambda 在2014年的发布，虽然展示了亚马逊云科技对 Serverless 的愿景，但不可否认的是，当时的 Serverless 技术仍旧不够成熟。直到本次 re:Invent 2022，Serverless 的冷启动速度得到大幅优化，大数据核心产品全面 Serverless 化完成，才宣告 Serverless 技术发展的又一里程碑到来，云产品全面 Serverless 化只剩下时间问题。

而 Serverless 在技术、产品两个方面的成熟，也直接为以上发布铺平了道路。试想如果这些产品不是围绕 Serverless 技术来进行设计的，那么所有构想都将成为灾难——没人能够忍受自动化创建业务流程的同时，还要关心服务器的配置问题。

这不只是在说 Serverless 技术好不好用，也是在说创新的门槛到底是高是低。如果你有了一个创意，Serverless 是最简洁的实现和验证手段，降低 Serverless 的使用门槛就是在降低业务的创新门槛——Application Composer 应运而生。

Application Composer 的特点在于可以帮助生成部署就绪的项目，例如 IaC 定义文件和 Lambda 函数代码脚手架。

在传统开发工作里，配置 Serverless 服务需要理解 IaC（基础设施即代码）的概念，并写一些机器可读的定义文件。这个概念作进一步延展，就变成了“基础设施可编程”。

Application Composer 无疑大大降低了开发者对 Serverless 技术的使用门槛，某种程度上也就是加速了企业的创新速度——当然，这也需要企业充分理解云理念，并对云原生相关技术有相对成熟的运用经验。

3D 世界的构建正成为主流

远瞻前路，Werner Vogels 博士在主题演讲中给出了他的大胆判断：未来 3D 会像视频一样普及。

去年，亚马逊发布具有 3A 游戏开发能力的开源游戏引擎 Open 3D Engine (O3DE)，基于 Lumberyard 系统开发而来。O3DE 改进了 3D 建模的界面、性能和编辑器，增加了「云」以及 Atom Renderer 交互等附加功能，支持 Vulkan、Metal 和 DirectX 12上的光线追踪，并且有着超过30种不同的开发工具。发布后，O3DE 立即引起了热议。

到2021年底，开放 3D 基金会（O3DF）宣布推出 O3DE 的第一个稳定版本，这是一个 Apache 2.0许可的多平台 3D 引擎，开发人员可以构建 AAA 级游戏、用于视频制作的电影级 3D 世界以及不受许可费或商业条款影响的非游戏使用案例模拟。

而本次 re:Invent 2022上的最后一个发布，也与 3D 有关—— Amazon SimSpace Weaver。

Amazon SimSpace Weaver 是一种全新的完全托管计算服务，可帮助用户在云中部署大规模空间模拟。借助 Amazon SimSpace Weaver，用户可以创建具有数百万个对象的无缝虚拟世界，这些对象可以实时相互交互，而无需管理后端基础设施。

结合去年发布的 Amazon IoT TwinMaker 来看，当下的 3D 技术脱胎于游戏，但已不止步于游戏。这项技术正在逐步完成现实世界的数字化模拟，处理性能快速提升。以 Amazon SimSpace Weaver 为例，数百万个对象的数字化模拟已经对以智慧城市为典型的行业应用产生了实际助推作用。