颠覆开发模式的创新发布背后，我看见了云计算的下一个十年
2022，在云计算的历史上是非常特殊的一年。基础设施加速创新和迭代、Serverless 迎来里程碑式的更新、数据实现 Zero ETL 集成且数据治理能力显著升级、人工智能持续加成被应用到更加丰富的场景...... 开发者的开发模式因为这些 re:Invent 创新的推动将产生颠覆式的改变，云计算也即将开启下一个十年的全新篇章。
在今年年末、re:Invent 中国行城市巡展活动开启前夕这个关键的时间节点，InfoQ 总编辑王一鹏独家专访了亚马逊云科技大中华区解决方案架构部总监代闻。本次专访不仅仅聚焦于最新发布的产品及服务，同时也从技术的实践与落地、创新与需求等多维度视角出发，代闻以其作为亚马逊云科技产品创新“领航员”的独特视角，向我们剖析了亚马逊云科技能够持续不断保持创新的动力所在，透过这次的深度对话，相信大家能够更加清晰地认识云计算的现阶段发展及未来趋势。
代闻：Nitro v5 、Graviton 3E 系列芯片的发布反映出当前的一个大趋势 —— 想提供一流的云服务，一定要具备底层硬件能力。只有通过底层充足的支撑和不断的创新，才能满足客户在云计算方面的需求。当然，创新不是凭空而来的，是由需求推动的。之前在技术圈子经常会说：好的软件工程师会给自己设计硬件。其实在云的时代也一样，一个优秀的云厂商，它在满足客户需求的时候，哪些是应该软件来做，哪些是应该硬件来做，需要良好的规划和路线。大家现在看到的 Nitro v5、 Graviton 3E，就是亚马逊云科技在这样的思路上，一直不断往前迭代的重大更新。
Nitro v5 进一步印证了硬件支撑虚拟化的技术路线，同时把安全做得更加牢靠。Graviton 3E 是在 ARM CPU 的这条路上又一个比较有里程碑意义的发布。之前有很多的机构都讲过，ARM 在数据中心里边的占比会越来越高，而亚马逊云科技真正把这个事情做出来，而且实现了量产，而且可以支撑客户的生产业务。到现在 Graviton 3E 其实是第四次发布，印证了 ARM 不仅仅是一个可选项，它现在变成我们要降本增效、要满足更多高性能场景的很重要的选项。
代闻：我可能不是从这个角度来看这个事情。云，其实是个服务，为了提供服务，你得有软件、有硬件、有算法，以及后台运营等等。硬件不是为了创新而创新，是因为用通用的硬件加软件优化的方式已经不够高效了，或者是内部底层功能做起来不够灵活了，跟不上创新速度了，所以反过来才做的硬件。
亚马逊云科技数据中心内部，最开始的时候也是用的商用的路由器交换机，后来是因为对于带宽、对于控制层面的灵活性有更高的诉求，亚马逊云科技就把内部的交换机全部应用了 SDN 技术，把整个平台构建起来。所以，不能说硬件的创新成为现在云计算的主流，而是我们可以通过硬件创新的方式，更好地满足客户的需求。除了硬件以外，还有软件方面的能力，我们很多时候在看云或者看产品的时候，往往会陷入到少数几个性能指标里，因为这个可能是最抓眼球或者是最便于理解的，但其实实际客户使用的时候，有很多的功能性需求的。如果亚马逊云科技只有底层的硬件，没有软件支撑，是不行的。所以，硬件创新是走到现在这个阶段里边非常重要的一环，但是它不是唯一的维度。
代闻：在我看来，现在在 HPC 领域里边的很多基准测试程序，体现在云计算的环境里边，是证明了在这个方向的上限能力。这个上限就决定了底层的基础设施的能力。无论这次发布的 Nitro v5、Graviton 3E ，还是重新把很多底层的通信用 SRD 的协议重新做部署。其实这就是拿 HPC 场景证明了云计算本身的能力。
在客户侧，我们看到近年来 HPC 在云上面是可以得到非常好的支撑，尤其是随着自动驾驶、药物研发投入需求增加，亚马逊云科技的产品研发团队就会比较切实地从用户需求出发来反推新的产品方向，进一步做底层创新，对这些场景加以支撑。从自动驾驶和药物研发，到欧洲粒子对撞实验室，都有过非常多的 HPC 的场景，但是之前从密度上来讲没有现在这么高，这两年虽然场景还是那些场景，但是，需求密度大大增加了，伴随着需求增加而进行的这些创新就可以提供更好的业务支撑和加速。
代闻：亚马逊云科技对于无服务器的计算环境的投入是非常早的，其实在 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 源中恢复出运行环境，来做迅速地扩展。以前冷启动是不能适应这种有负载抖动的场景的，现在它可以无缝地扩展、收缩。这样一来，能够让大家更加专注在应用代码的编写上面并将适用边界拓展到更加有挑战性的场景里面去。
代闻：一方面是用户的需求，另外一方面从技术上分析。Serverless 第一步是最基本的计算环境 Serverless，第二步，第三方代码能不能托管进去？所以在技术方面，有了 Serverless 的便利性以后，下一步就是平台软件的 Serverless 化。现在的平台软件里数据相关的软件比较多。数据库也好，数据分析软件也好，本质上就是一个系统，它自己就是一个平台软件，既然代码运行环境可以 Serverless 化，把这个技术应用到平台软件，就很自然的推动了 Serverless 化全面改造。
代闻：当我们谈一个产品或者技术的未来，我们需要先设定多大的时间维度。其实很多产品的创新是持续性的，是一步一步往前推进的。我们对于不同的客户，不同的工作负载提供了不同的工具，客户自己会选择最合适的产品，而且每个产品都有自己的参考架构。有的客户业务场景适合全部用 Serverless ，有的场景可能发现还是容器或者虚拟机这样的方式会更适合。然后，当用户发现 Serverless 的使用在他们的业务场景里还是有限制的时候，新的需求就会产生，反推我们做下一个迭代。所以云服务创新很关键的一点是，真正的从用户的需求出发，来反推技术的演进，而不是关门站在技术的制高点上面，研究出一个工具，让大家一定要用。
代闻：整个的云计算历程是始于开发者和一些初创公司的，然后再被大的企业接受、在企业领域应用和创新。开发者是云计算功能、性能不断地做创新，一直能往下走的一个非常重要的引擎。在整个的亚马逊的版图里，开发者是非常非常重要的，也是能保障亚马逊云科技的产品、服务，最后的落地能力足够强的很重要的保障。
再回到具体的特点中，Amazon Step Functions Distributed Map 可以看作是在云原生的环境下，对于开发者提供的更加有利的一个工具。说到云原生，什么是云原生？云原生是程序从第一天就是在云上跑的，根本不需要考虑如果放在机房里面是怎么样。比如，现在有 100 万个日志文件在 Amazon S3 上面，想要对文件里边的某一个字符进行更改。这个时候就要对很多的日志文件，同时进行更改操作，需要有非常大的并发。如果没有 Amazon Step Functions Distributed Map 就需要 Launch 一个大数据的服务，然后通过数据处理来做，但现在有了 Amazon Step Functions Distributed Map 以后，就可以屏蔽底层的复杂度、非常轻松地来实现这个处理。这样一来，就可以真正地进一步完善云原生环境里边的开发体验。
云原生影响的不只是我们程序的运算环境，还会影响到开发者的默认前提。云原生时代的开发者，他的需求包括对于工具的抽象程度，其实和以前是不一样的。我们需要把工具做足够好的抽象，让大家在云原生状态下进一步地聚焦在业务上面，不用关心底层逻辑。云原生，它是相对概念。刚上云的时候，云原生可能指的是弹性、高可用这些，但走到现在，可能是平台、操作、数据处理等。云原生不是绝对的，因为云服务本身的边界在不断变宽、变多，云原生是相对于什么时候的云原生，十年前的云原生还是现在云原生，是不太一样的。
代闻：低代码也是相对概念，是一个过程。低代码可以以发展进程式的方式来理解。Amazon Step Functions 也有一个叫 Workflow Studio 的低代码可视化工具。Amazon Step Functions 一整套工具集与低代码有相同的实现目的，即能够把一些重复的、晦涩难懂的工作用更加简易的、可视化的方式实现，所以，如果站在更高层面上，把低代码看作是技术往下一代演进的一个过程，那么 Amazon Step Functions 和低代码就是在同一个维度上面的，更何况 Step Function Workflow Studio 本身就是一个低代码类的产品。
代闻：Amazon CodeCatalyst 更多的是关注云原生的开发环境。在我看来 Amazon CodeCatalyst 的特色主要有两点。第一，它覆盖到了开发的整个生命周期。从最开始的规划，到软件架构的设计，再到底层的系统架构的采用，再到编码，其实都是可以在这个平台里边来完成的。第二，开发环境和协作环境都是在云端完成的，这样一来，对于内部协作的统一性，开发的便利性，都能得到很好的保障。每一次新的服务发布以后，就是新的领域或者一个新的方向的开始，我相信 Amazon CodeCatalyst 在接下来也会接收到很多用户的输入，让它不断迭代。同时 CodeCatalyst 也兼容很多合作伙伴产品，大家会一起前行。
代闻：Werner Keynote 里边最开始谈的是并行以及异步，他认为，异步是并行很重要的支撑。Werner Keynote 谈到在现代的软件开发架构下，如何构建一个松耦合的高并发系统，这正是现在很多的开发者会遇到的问题。虽然微服务已经提出很长的时间，但是大多数企业依然需要让软件架构往前演进。其关键在于，首先是能够把握住业务需求，第二，是要有好的设计原则、并且遵循设计原则，进而灵活的支撑业务需求。去年， Werner 也分享了他的 API 设计的原则，但是真的落地的时候，由于种种原因，大家还是会遇到很多困难。
亚马逊看到了这些难点，然后针对很多共性需求开发了一系列抽象服务，屏蔽底层实现的复杂度，让更多中小企业和开发者可以轻松推进软件架构演进，实现云原生。例如，Amazon Step Functions Distributed Map 就是这样一个服务，对于大规模并发的数据处理，开发者不用再自己实现并发机制，在云原生的环境里更加专注业务需求。
代闻：这取决于我们从多大的历史维度看这个问题。因为云服务本身是一个服务，服务的本身是要帮助使用者、客户实现自己的业务目标。技术实现来源于需求，反过来，有新的技术以后又能够进一步拓宽边界和可能性，客户又可以在新的方向去试验，一起把推动云计算向前发展。如果一定要找一个维度来看云计算处在什么阶段，那么，从现在企业的 IT Spending 来看，它还是早期的。
以上内容根据采访视频整理，以视频内容为准
为了将 2022 亚马逊云科技 re:Invent 全球大会的精华内容和体验带给中国众多云计算爱好者，亚马逊云科技将于 12 月 20 日开启 2022 re:Invent 中国行城市巡展活动，实现“全球盛会，中国共享”！戳阅读原文，了解 2022 re:Invent 中国行的详细信息。
给大家分享一份整理的 Java 学习资料——《10 小时掌握 Java 进阶必备技术栈》，内容包含有项目性能优化、JVM 虚拟机、多线程等这些必备知识点，从基本概念介绍，到代码实践练习内容非常全面！
现在扫描下图二维码，即可免费领取内容！课程内容搭配的全套代码资料以及数据也都可以一并免费获取！