颠覆开发模式的创新发布背后，我看见了云计算的下一个十年

2022，在云计算的历史上是非常特殊的一年。基础设施加速创新和迭代、Serverless 迎来里程碑式的更新、数据实现 Zero ETL 集成且数据治理能力显著升级、人工智能持续加成被应用到更加丰富的场景...... 开发者的开发模式因为这些 re:Invent 创新的推动将产生颠覆式的改变，云计算也即将开启下一个十年的全新篇章。

在今年年末、re:Invent 中国行城市巡展活动开启前夕这个关键的时间节点，InfoQ 总编辑王一鹏独家专访了亚马逊云科技大中华区解决方案架构部总监代闻。本次专访不仅仅聚焦于最新发布的产品及服务，同时也从技术的实践与落地、创新与需求等多维度视角出发，代闻以其作为亚马逊云科技产品创新“领航员”的独特视角，向我们剖析了亚马逊云科技能够持续不断保持创新的动力所在，透过这次的深度对话，相信大家能够更加清晰地认识云计算的现阶段发展及未来趋势。

云基础架构的构建之路InfoQ：本次 re:Invent 大会 Nitro v5 、Graviton 3E 系列芯片是很多人期待的发布，那么，对行业有何意义，我们应该如何去理解现在整个云计算产业在硬件方面的更新？

代闻：Nitro v5 、Graviton 3E 系列芯片的发布反映出当前的一个大趋势 —— 想提供一流的云服务，一定要具备底层硬件能力。只有通过底层充足的支撑和不断的创新，才能满足客户在云计算方面的需求。当然，创新不是凭空而来的，是由需求推动的。之前在技术圈子经常会说：好的软件工程师会给自己设计硬件。其实在云的时代也一样，一个优秀的云厂商，它在满足客户需求的时候，哪些是应该软件来做，哪些是应该硬件来做，需要良好的规划和路线。大家现在看到的 Nitro v5、 Graviton 3E，就是亚马逊云科技在这样的思路上，一直不断往前迭代的重大更新。

Nitro v5 进一步印证了硬件支撑虚拟化的技术路线，同时把安全做得更加牢靠。Graviton 3E 是在 ARM CPU 的这条路上又一个比较有里程碑意义的发布。之前有很多的机构都讲过，ARM 在数据中心里边的占比会越来越高，而亚马逊云科技真正把这个事情做出来，而且实现了量产，而且可以支撑客户的生产业务。到现在 Graviton 3E 其实是第四次发布，印证了 ARM 不仅仅是一个可选项，它现在变成我们要降本增效、要满足更多高性能场景的很重要的选项。

InfoQ：云计算已经步入硬件主导性能提升的时代了吗？这种说法是正确的吗？

代闻：我可能不是从这个角度来看这个事情。云，其实是个服务，为了提供服务，你得有软件、有硬件、有算法，以及后台运营等等。硬件不是为了创新而创新，是因为用通用的硬件加软件优化的方式已经不够高效了，或者是内部底层功能做起来不够灵活了，跟不上创新速度了，所以反过来才做的硬件。

亚马逊云科技数据中心内部，最开始的时候也是用的商用的路由器交换机，后来是因为对于带宽、对于控制层面的灵活性有更高的诉求，亚马逊云科技就把内部的交换机全部应用了 SDN 技术，把整个平台构建起来。所以，不能说硬件的创新成为现在云计算的主流，而是我们可以通过硬件创新的方式，更好地满足客户的需求。除了硬件以外，还有软件方面的能力，我们很多时候在看云或者看产品的时候，往往会陷入到少数几个性能指标里，因为这个可能是最抓眼球或者是最便于理解的，但其实实际客户使用的时候，有很多的功能性需求的。如果亚马逊云科技只有底层的硬件，没有软件支撑，是不行的。所以，硬件创新是走到现在这个阶段里边非常重要的一环，但是它不是唯一的维度。

InfoQ：C7gn 和 HPC7g 都是服务密集型工作负载的实例，这是否说明云计算下一阶段的主要技术攻坚方向会聚焦于自然科学、工程、气象这些领域？

代闻：在我看来，现在在 HPC 领域里边的很多基准测试程序，体现在云计算的环境里边，是证明了在这个方向的上限能力。这个上限就决定了底层的基础设施的能力。无论这次发布的 Nitro v5、Graviton 3E ，还是重新把很多底层的通信用 SRD 的协议重新做部署。其实这就是拿 HPC 场景证明了云计算本身的能力。

在客户侧，我们看到近年来 HPC 在云上面是可以得到非常好的支撑，尤其是随着自动驾驶、药物研发投入需求增加，亚马逊云科技的产品研发团队就会比较切实地从用户需求出发来反推新的产品方向，进一步做底层创新，对这些场景加以支撑。从自动驾驶和药物研发，到欧洲粒子对撞实验室，都有过非常多的 HPC 的场景，但是之前从密度上来讲没有现在这么高，这两年虽然场景还是那些场景，但是，需求密度大大增加了，伴随着需求增加而进行的这些创新就可以提供更好的业务支撑和加速。

Serverless 化全面改造InfoQ：前几个问题主要跟代闻老师聊了关于 Infra 的发布，以及对于云计算行业来说有着什么样的意义。接下来想聊一下 Serverless。本次 re:Invent 发布了 Amazon Lambda SnapStart，能否为我们解读下这一发布对行业的价值，以及是如何实现的？

代闻：亚马逊云科技对于无服务器的计算环境的投入是非常早的，其实在 Amazon Lambda 刚出来的时候，很多人不太看好，因为跟多年以前的 Runtime 托管非常像。并且，在 Lambda 推出的 2014 年，那个时候大家讲的更多得还是从虚拟机到容器。但是亚马逊云科技当时坚持认为，以后无服务器和容器都会占据非常重要的位置。

其实我认为无服务器，更多的是一种计算环境的体现，或者是从用户角度来判定“我”需要一个什么样的计算服务或者是一个平台服务。在最开始的时候，我们狭义上的 Serverless 是 Amazon Lambda，来运行我们自己的代码。后来，开发者想要把第三方软件或服务也能够 Serverless 化（以同样获得弹性、免运维等益处），现在才看到了诸如 EMR Serverless、Aurora Serverless、Redshift Serverless、OpenSearch Serverless 等产品形态的的出现，同时第三方软件服务的 Serverless 版本也逐渐成为标配。

具体回到 Amazon Lambda 里，亚马逊云科技一直在不断地把 Amazon Lambda 的使用边界拓宽。在最开始的时候，冷启动，甚至是在 VPC 的访问方面都有一些限制。后来你会看到它一步一步地去做增强，一部分是性能方面，一部分是功能需求方面。

功能需求方面，一开始 Amazon Lambda 的开发环境都成问题，本地开发环境也不太友好，但现在整个的工具链是非常成熟的。性能方面，从最开始的发布到 Firecracker microVM 技术的引进，再到现在的 Amazon Lambda SnapStart ，它是把运行环境里边的内存和磁盘做镜像， 把初始运行环境 Cache (缓存) 起来。当你要运行代码的时候，它立马能够从 Cache 源中恢复出运行环境，来做迅速地扩展。以前冷启动是不能适应这种有负载抖动的场景的，现在它可以无缝地扩展、收缩。这样一来，能够让大家更加专注在应用代码的编写上面并将适用边界拓展到更加有挑战性的场景里面去。

InfoQ：能否为我们聊聊亚马逊云科技是如何针对云产品，推进 Serverless 化全面改造的？

代闻：一方面是用户的需求，另外一方面从技术上分析。Serverless 第一步是最基本的计算环境 Serverless，第二步，第三方代码能不能托管进去？所以在技术方面，有了 Serverless 的便利性以后，下一步就是平台软件的 Serverless 化。现在的平台软件里数据相关的软件比较多。数据库也好，数据分析软件也好，本质上就是一个系统，它自己就是一个平台软件，既然代码运行环境可以 Serverless 化，把这个技术应用到平台软件，就很自然的推动了 Serverless 化全面改造。

InfoQ：所以代闻老师觉得我们现在 Serverless 的实践整体进展到什么样的阶段？它距离我们未来的一个理想目标大概还有多远？

代闻：当我们谈一个产品或者技术的未来，我们需要先设定多大的时间维度。其实很多产品的创新是持续性的，是一步一步往前推进的。我们对于不同的客户，不同的工作负载提供了不同的工具，客户自己会选择最合适的产品，而且每个产品都有自己的参考架构。有的客户业务场景适合全部用 Serverless ，有的场景可能发现还是容器或者虚拟机这样的方式会更适合。然后，当用户发现 Serverless 的使用在他们的业务场景里还是有限制的时候，新的需求就会产生，反推我们做下一个迭代。所以云服务创新很关键的一点是，真正的从用户的需求出发，来反推技术的演进，而不是关门站在技术的制高点上面，研究出一个工具，让大家一定要用。

云如何成为创新时代的核心InfoQ：在 re:Invent 上，亚马逊高级副总裁、CTO Werner Vogels 发布了许多对开发者有重大意义的产品，Amazon Step Functions Distributed Map 为何会聚焦并发数量的变化，是我们基于什么样的需求来做的产品迭代？

代闻：整个的云计算历程是始于开发者和一些初创公司的，然后再被大的企业接受、在企业领域应用和创新。开发者是云计算功能、性能不断地做创新，一直能往下走的一个非常重要的引擎。在整个的亚马逊的版图里，开发者是非常非常重要的，也是能保障亚马逊云科技的产品、服务，最后的落地能力足够强的很重要的保障。

再回到具体的特点中，Amazon Step Functions Distributed Map 可以看作是在云原生的环境下，对于开发者提供的更加有利的一个工具。说到云原生，什么是云原生？云原生是程序从第一天就是在云上跑的，根本不需要考虑如果放在机房里面是怎么样。比如，现在有 100 万个日志文件在 Amazon S3 上面，想要对文件里边的某一个字符进行更改。这个时候就要对很多的日志文件，同时进行更改操作，需要有非常大的并发。如果没有 Amazon Step Functions Distributed Map 就需要 Launch 一个大数据的服务，然后通过数据处理来做，但现在有了 Amazon Step Functions Distributed Map 以后，就可以屏蔽底层的复杂度、非常轻松地来实现这个处理。这样一来，就可以真正地进一步完善云原生环境里边的开发体验。