未来计算的十大趋势预测

未来计算的十大趋势预测
WASM 将无所不在：编译目标、部署目标、IoT、插件生态系统。

这是正在发生的事。

（1 到 5 年）
Rust 的流行度将继续增加，未来几年有望在RedMonk 排行榜上超过 Go。

（2 到 4 年）
Kubernetes 将迎来重要对手。

如果它使用 WASM，并支持 GitOps 风格的模型，会是加分做法。

（2 到 5 年）区块链生态系统将会崩溃，谁知道什么时候呢。

也许会悄悄地发生，几年后我们将谈论“区块链的冬天”。

谁知道呢？（1 到 10 年）
供应链安全将是一个大问题。

在未来两年内，将会有更多像 SolarWinds 这样规模的黑客组织（可能已经有了，只是我们不知道）。

供应链工具（我不愿意称之为“解决方案”）将是一个很大的增长点，但要在行业内被广泛接受（例如，让每个人都使用 SBOM）仍然有很漫长的路要走。

（大约 2 到 10 年）本条勉强算是一个预测，无服务器将继续增长，而且慢慢会成为主流范式。

（10 年？Kubernetes 还有很大的发展空间。

）不过，在人们学会使用新范式设计系统架构之前，它还会经历更多的反弹和“失败”。

（未来 2 年）
我们将会看到，企业为了节省成本，会部分地迁回到本地数据中心。

（2 到 5 年）
这可能是本文最具争议 / 不可能的观点。

有那么丁点可能会出现百亿级的 AI 公司，利用智能合约奴役全人类。

（10 到 20 年）
好吧，虽然不希望，但 AI/ML 的发展还是有可能在多个行业中造成大规模的破坏。

我不认为我们会发展出一种通用人工智能，但在具体的领域会有大的飞跃。

这可能会导致大量工作岗位消失，比如卡车司机。

我们可能会很惊讶，竟然是那些行业受到影响。

（2 到 10 年）（我不知道何时会发生，但变化可能突然到来。

）
类似的，GPT3 类的助手（高效地自动完成所有事情）将广泛应用。

艺术家、作家、开发人员、操作人员、作曲家都会使用。

（1 到 4 年）
编程语言
首先声明，我不是一名编程语言专家。

我认为有些领域自己需要多了解一下，这是其中一个，我很愿意多做些研究。

最近几年，似乎有一种向类型化语言转变的趋势，最明显的是 TypeScript 和 Rust。

现在大多数 JavaScript 框架都使用了TypeScript。

根据最近的GitHub Octoverse 报告，TypeScript 是 10 大编程语言之一。

我认为 Rust 的流行度也会有很大的提升，越来越多的底层软件使用 Rust 编写，还有些是为了安全性和性能而移
植到 Rust。

此外，它也非常适合 WebAssembly（WASM）生态系统，因为它可以编译成一个很小的 WASM 二进制文件，这归功于它没有运行时或垃圾收集（GC）。

在现代编程语言中，没有垃圾收集可谓是异类，这源于 Rust 非同寻常的内存模型以及所有权和借用的概念。

看下 RedMonk 排行榜，再考虑下推动 Rust 发展的因素，在未来几年，Rust 的流行度很可能会超过 Go。

再长远点看，我认为会有新的语言流行，它们基于Rust 的概念构建（主要是内存模型 & 借出 - 检查），并且提供比较高级的特性。

我认为会有一种从属类型的语言（如 Idris）将类型系统带入下一个层级，从学术界（或业余语言）进入行业并成为流行的语言。

在开发微服务，尤其是使用了 Kubernetes 时，所使用的语言最好是那种可以生成比较小的独立二进制文件的。

此外，可以编译成 WASM 的语言也可能变得越来越重要，因为我们可以借此访问各种 PaaS 和边缘平台。

这两个因素可能会限制 Elixir、Gleam 这类语言的增长（它们基于 Erlang VM）。

（注意：像 LUMEN 这样的项目可能会证明我这里的说法是完全错误的。

）
Kubernetes 和部署平台
未来 5 年，Kubernetes（又称 k8s）将继续增长。

但是，如果它不能做些什么来解决快速增加的复杂性，那
么我们就会看到有强有力的竞争对手开始出现。

我们正在进入这样的阶段，运行和管理 Kubernetes 变得太过复杂，用户转向使用像 GKE 这样的托管服务，或者是雇佣专业的公司如 Giant Swarm 和 Container Solutions 来管理Kubernetes。

即使是使用了托管服务的公司，也会寻求专业公司的支持。

这不一定是坏事（这些服务让组织可以专注于业务），但也确实意味着，那些不愿意为这些服务付费的客户将会被更简单的解决方案所吸引。

值得注意的是，这种复杂性并不是隐藏不见的。

它已经浮出水面，影响到了用户。

尝试用 kubectl run 命令启动并运行一个 Demo 很简单。

但运行生产应用，并弄明白如何安全地暴露出去就需要了解一大堆不同的特性了，不可避免地，这就需要编写比微服务源代码还要长的YAML 文件了。

为什么会这么复杂？这在很大程度上是逐步演化而来的。

开始的时候，我们做的事情很简单（使用Kubernetes 时更简单），然后其中加入了对用例 x 的支持。

接下来，我们认识到，如果它能做 z 这件事会更好，于是就重写了一些东西，但得保持向后兼容性。

这就导致了问题本身并不存在的复杂性（额外的复杂性）。

这意味着会有新的竞争者出现并取代它，因为它们没有历史包袱，可以汲取前人的成果，避免前人的错误。

换个说法，所支持的用例数量的增加导致了“80/20”问题，80% 的用户仅使用 20% 的特性，但每个用户所使用的 20% 并不相同。

要想去掉特性很困难。

新的竞争者则不存在这个问题，他们可以围绕一个比较小的核心功能集构建一个新产品，并且可能修复 / 避免其他问题（100 英镑赌他们不用 YAML）。

和之前一样，我们先看小规模的变化。

小型公司和个人将避免使用 k8s，而选择更简单的解决方案，可能是某种开源的 PaaS，而且很可能使用 WASM。

未来几年，Nomad 的使用可能会开始增加。

开始的时候人们会说，“可以，但不用大规模使用 x”，但是慢慢地，问题解决了，有一场行业巨变将在我们眼前发生。

还有一种可能是，Kubernetes 成为底层基础设施层，其他东西都以此为基础进行构建。

因此，小项目可以使用看上去很简单的 PaaS（如像 Knative 这样的 FaaS），但是，PaaS 是基于 k8s 的。

由于 Kubernetes 对资源的要求很高，以及其复杂性的日益暴露，所以我有点相信，这种做法会被大量采用。

将 k8s 的优点提取到一个新系统中可能更简单、更有效——在这方面，已经有许多探索性的工作，如 k3s、KCP 和 badidea。

顺便提下，在大型组织中，像 Backstage 和 Crossplane 这样的内部平台
和工具将变得非常常见，即使 Kubernetes 消失了，它们也不会。

（如果你对构建 Kubernetes 终结者感兴趣，那么Prolog 和这个讨论值得一看。

）
不管发生什么，Kubernetes 都会以某种形式长期陪伴我们。

它仍然在快速演化，我们看到，有一些技术很可能影响未来几年。

自定义操作符和 GitOps 将变得很普遍。

一些创新性的Kublet 实现如Krustlet（支持将WebAssembly 模块作为 pod 运行）可能会开始受到追捧。

WASM
WebAssembly 已经出现几年了，但现在，它已经准备好大显身手了。

要理解其中的原因，可能最简单的方式就是回想（假如你已经有了一定的年级）下 Java 最初喊出的口号：“一次编写，到处运行”。

我们被告知，Java 在哪里都可以运行，完全可移植。

它取得了巨大的成功，但完全没有达到声称的水平。

为什么呢？
它很慢（至少人们是这样认为的），而且很耗内存。

尤其是在边缘，它完全没有用武之地。

你需要学习 Java（现在有许多种 JVM 语言，但以前的选择很有限）。

编写 JVM 实现很难，而且各种实现之间的差别给“一次编写，到处运行”埋下了祸根。

在浏览器中运行（Applet）需要安装插件。

WASM 解决了所有这些问题。

它相对更简单、高效，而且更小。

许多语言都可以编译成 WASM。

主流的浏览器中都已经有了成熟的实现。

其安全性也很有说服力——WASI 项目让你可以控制 WASM 可以做什么，可以读取什么输入，可以向哪里写以及可以进行什么内核调用。

我们已经看到，有多个项目在其插件系统中使用了WASM，包括 Envoy 和 Ethereum。

其应用只会扩大，因为它是如此有用。

你可以在一个很细的粒度上控制插件可以访问什么，同时又允许用户可以选择任何他们喜欢的语言来编写插件。

在许多情况下，WASM 取代了容器，我希望看到更多与 Kubernetes 的整合，以 Krustlet 已经展现出的潜力为基础构建。

更有意思的是，使用 WASM 来支持新的 PaaS 和FaaS 平台，包括Fastly compute@edge 和Cloudflare workers。

我们也看到了它在边缘的应用，这主要归功于其可移植性和磁盘空间占用小。

话虽如此，WASM 还面临着许多挑战。

我在上文中提到，已经有许多语言可以编译成 WASM。

这是真的，但这种支持参差不齐。

Rust 似乎是排名第一的语言，因为它提供了很好的支持，而且生成的文件相对较小（得益于前
面提到的没有 GC 和运行时）。

AssemblyScript（一个面向 WebAssembly 的 TypeScript 版本）也很受欢迎。

虽然包括 Go 在内的其他语言提供了不错的支持，但往往因为垃圾收集器实现或运行时特性导致文件很大。

其他语言实现基本还在起步阶段。

许多重要的基础设施项目如WASI（该项目定义了WASM 如何与主机环境交互）也是如此。

ByteCode Alliance 应该在生态系统快速构建方面发挥重要的作用。

供应链安全
作为一个行业，我们在这方面做得一直很糟糕（部分原因是安全行业的激励机制遭到了破坏）。

令人惊讶的是，这并没有导致攻击行为增加。

我们会越来越多地看到，组织不经意间就运行了已“中毒”的软件版本，因为攻击者已经能够在某个阶段注入自己的软件——可以是编译期间，也可以是分发阶段或升级过程中。

在某些情况下，你可能会面临支付加密赎金的窘境，但是，我们将会看到“智能攻击”越来越多，它们会以已经被攻破的组织为跳板攻击其他组织（如 SolarWinds）。

要解决这个问题，首先得想一下如何证明生产环境中运行的组件的来源。

当务之急是让 SBOM 以及类似的元数据成为标准做法，并普遍应用像 in-toto 和 Notary v2 这样的工具。

下文介绍的 GitOps 也可以发挥一定的作用，
它对 CI 权限和部署权限做了清晰的划分，并且让我们很容易弄清楚谁为什么做了什么修改。

未来，攻击的潜在影响可能非常大，这已经引起了政府的注意。

白宫已经发出了审核美国政府软件供应链的指令，英国也在就供应链网络安全征集意见。

希望这是协同改进标准实践、构建攻击防御工具生态的起点。

乐观的预测是，这些项目和方法（或类似的东西）会得到有效的应用。

悲观的预测是，它们没有得到有效的应用，我们会越来越频繁地看到越来越具破坏性的供应链攻击。

区块链与加密货币
兄弟们，对不起，虽然我认为区块链有其用途所在，但这个领域的大多数公司还是会失败。

在这个生态系统中，没有足够多可行的案例证明资金投入的合理性。

如果你在这个领域，那么我希望你是卖铲子的。

有一个领域或许会证明我是错的，那就是智能合约。

也许，这只是因为它让我想起了 Accelerando——我们可以让 AI 基于智能合约构建一个帝国吗？（那么智能合约将用什么来写？你猜对了，WASM。

）另一个可能的应用场景是上文提到的供应链安全——是否可以使用区块链来识别软件的来源？
对于更普遍的“加密货币”，我希望看到有一种真正的方式可以实现小额支付和低成本（接近零成本）国际汇款。

我确信，这是加密货币的承诺之一，但至今还没兑现。

当前，像 Coinbase 这样的公司，其收费明显高于股票经纪公司对类似服务的收费。

我们必须终止 Proof-of-Work 算法所造成的荒唐的资源浪费。

短期来看，Proof-of-Stake 似乎是唯一可取的替代方案，我们必须转向这种模式。

我真心希望看到比特币的终结，但其所占用的资金量和所拥有的支持者数量意味着这在短期内不会发生。

对于 NFT，我还是持怀疑态度，但我很喜欢今年早些时候的这篇文章。

GitOps 与 x-as-code
GitOps 的理念非常非常简洁，即将 Kubernetes 集群所需的状态保存在 Git 中。

如果集群的实际状态出现异常，就进行调整（隐藏了很多不同的可能性）。

当需要更改状态时，Git 存储库会更新，然后集群会轮流“调整”。

这样做有一个很明显的好处，就是我们仅仅克隆该存储库就可以创建一个完全相同的集群，所有的变更都有完整的日志，我们还建立了一种讨论以及审批变更（拉取请求）的机制。

然而，实现 GitOps 并不像听上去那么简单，也
存在许多与之竞争的技术，包括 Kubestack、Flux 和Argo CD。

我们已经把 GitOps 应用到 Kubernetes 下的技术栈里，例如使用 Terraform 创建集群。

随着微服务、无服务器、服务网格和队列、数据库等 SaaS 组件的兴起，曾经的应用程序问题（如将功能连接在一起）已经被推入了集群或基础设施层。

基于此，我们显然可以推断出，YAML 文件已不足以构建和定义集群。

我们需要成熟的编程语言。

Pulumi 很早就看到了这一点，并抓住了机会，但我认为，我们还会看到许多轮的迭代和潜在的解决方案。

再一次，WASM 可以在这方面发挥一些作用，让用户可以引入自己的编程语言。

关于这一点，未来几年就会清晰，但我预计，许多手写的 YAML 会被 CDK、Pulumi 及类似的产品（更容易读取和推断）所替代，YAML 和 CloudFormation 将成为编译目标。

无服务器与 FaaS
上面这一点导致了 FaaS 解决方案（如 Lambda）的应用。

这一定会发生，但不像一些支持者所认为的那样是一项明确而简单的变化。

要想有效地使用 FaaS 需要设计一种不同的应用程序架构风格。

队列和消息传递基础设施成为必不可少的组件，要想构建可靠的服务，就要先从根本上了解它们的交互性。

对于以前可以通过数据结构和函
数调用的事情，现在必须重新建模，并作为一个支持错误处理的分布式系统来考虑。

这个领域的最佳实践和设计模式可能需要过一段时间才能够标准化并转变为常识。

与此同时，我并不清楚，Lambda 是否能承担起所有这些工作。

Cloudflare 和 Fastly 的边缘计算 FaaS 服务很有吸引力，它们提供了令人印象深刻的性能和可扩展性，并通过 WASM 提供了语言灵活性。

缺点是，它们缺少来自云提供商的基础设施支持，而且这些云提供商也在构建自己的 CDN，从而弱化了 FaaS 的优势。

所有这些服务都是专有的，使得许多公司都怕被锁定。

为此，像 Knative 和 OpenFaaS 这样的替代方案会受到欢迎，加剧市场的碎片化。

广义上讲，无服务器（既包括 FaaS，也包括像数据库和队列这样的 SaaS）将成为主导模式，但要走的路可能比我们预想的更坎坷。

未来几年，我们将既会看到成功的故事（“我们通过迁移到无服务器每月节省了 1 万”），也会看到灾难性的故事（“我们放弃了无服务器，因为那每月要花掉我们 1 万”）。

AI 与机器学习
这个难以预知的领域让我有点害怕。

我接触过一些运行智能合约的公司，但在我看来，他们其实是科幻迷而非实用主义者。

看看 GPT3（原论文）可以做什么，我们就
可以更好地了解正在发生的一切了。

我能否写一篇博文，其质量可以和乔治奥威尔的论文相媲美？是否所有的作者都开始使用 AI 作为合著人和编辑？卡车驾驶是美国最大的就业来源之一——未来 10 年，将会有多少司机会被 AI 取代？有多少行业的多少岗位会被取代？（更多更好的预测，请阅读 Sam Altman 的文章和采访）或者，只是另一轮炒作？
短期内，最主要的变化可能是基于 GTP3 及其后继算法的 AI“助手”和“自动补全”将无处不在。

如果你正在写一篇博文，那么它会帮你补全句子。

如果你正在开发一个 Web 应用，那么它会帮你补全方法。

如果你正在写一首歌，画一幅画，草拟一份工程计划，它都随时可以帮助你。

如果你回避这种帮助，就可能被别人甩在后面。

具体到云计算的发展，这体现在了 AI Ops 的增长上，机器学习被用来分析从正在运行的应用程序中收集的日志和遥测数据，从而发现问题和需要优化的地方。

我不认为我们很快就可以开发出一种通用人工智能，这种大幅的变化只会出现在几种特定的行业和用例中。

但给这些行业带来的变化仍然可能是一场彻底的革命。

这些变化可能在突然之间发生，好处会被少数拥有这项技术的公司所包揽，进一步加剧社会的经济分裂。

我的恐惧源于，我甚至都没有想象出其中的一些可能性，而 AI 变革几乎是一夜之间就发生了。

科幻作者经常说“奇点”，广义上讲，这是说当 AI 发展超过了特定的点，变化会加速，人类将无法预测或跟上这种发展。

在这方面，有一些观点可能比较夸张，但我绝对相信，AI 将产生我们未能预见到的重大社会影响。

混合基础设施的兴起
当前，本地部署、裸机和混合部署市场似乎都很活跃，既有新玩家，也有老玩家。

我对这个领域的关注不是很多，所以可能会跑题，但我还是要继续说。

外表上看，可能会觉得一切都在不可避免地走向公有云，但我认为，我们已经开始回到本地部署和混合部署。

一路走来，传统硬件公司，如戴尔、HPE，可能已经犯下了很多错误，他们似乎全都转向了 *aaS 模型，客户只需要按使用付费。

起初，这听上去似乎与拥有本地硬件不相符，但据推测，这意味着供应商提供硬件时会存在能力冗余，并且保证在需要时快速提供更多的硬件。

关于这个模型，有一件有趣的事情是，可以平衡投入、资本支出和运营支出。

想降低单实例月成本？签一份 5 年期的合同或提前购买硬件。

因为业务模式没确定而想要一种更灵活的模型？签一份一年期的合同，但单实例成本更高。

HPE 的 GreenLake、Dell 的 Apex 项目就是这一模型的例子。

考虑下 IBM 最近的收购以及其已有的产品和解决方案，我们有理由推测，他们也在采取类似的市场举措。

在这个领域，Nutanix 也明确提供了一个软件控制平面，支持云资源或本地硬件。

控制平面的重要性再怎么强调也不过分，因为只有可以轻松整合混合资源并维护基础设施时，该模型才有效。

在这个领域，新玩家 Oxide 大概也有一些创新计划，在硬件和管理程序的各软件层之间提供更好的集成。

值得注意的是，这与 Equinix、Scaleway 等裸金属和数据中心公司当前提供的以及正在构建的东西差别并不是特别大——也许差别就在于我们所说的“本地”是什么意思。

这是说硬件只运行在自己的数据中心里，还是说硬件是我的，但可以运行在其他人的数据中心里？我必须拥有硬件吗，还是也可以租用？
在此背景下，云提供商和芯片制造商之间的关系也在发生有趣的动态变化。

云提供商希望芯片可以互换，这样芯片就会更便宜，每隔几年就可以更换。

芯片制造商希望尽可能多地把芯片卖给云提供商，同时又保持对市场的掌控。

为了保有拥有不同需求的多样化客户群，芯片制造商会支持 HPE 和戴尔的举措，以及其他有利于推动本地和
边缘计算平台多样化的工作。

相比之下，云提供商已经开始构建自己的定制芯片，并推向本地部署市场。

此外，云提供商和 CDN 提供商（如 Cloudflare、Fastly）之间也存在着激烈的竞争。

这两家公司都已经开始提供无服务器计算服务，他们使自己的数据中心尽可能地靠近用户（边缘计算的一种形式）。

因为离终端用户很近，所以他们有很大的速度优势，似乎也有成本优势。

他们也有一个很大的缺点，就是提供的功能不如 AWS 等云提供商广泛——一般来说就是提供数据存储和计算服务，其他的就很少了。

虽然我预计这些服务会迎来大幅增长，但云提供商也会积极地进入 CDN 领域发起反击。

出于降低成本和避免锁定的考虑，我们将看到一些公司开始迁回本地 / 混合部署。

云将继续占据主导地位，尤其是在创业领域，但成熟的公司将会探索节省运营支出的可能性。

也许，更困难的问题是，谁将是这场运动的最大赢家——传统的硬件提供商、裸金属和数据中心提供商、边缘计算提供商、云提供商，还是管理平面软件提供商？
量子计算
量子计算这个领域我了解的少之又少，说的可能是胡话。

鉴于量子计算需要真空和接近绝对零度的温度，我们不大可能在短时间内获得量子笔记本。

事实上，其成本如
此之高，只有大企业和政府才负担得起量子计算机的成本。

不过，这并没有将公众赶出量子计算领域——主流云提供商都已经宣布研究量子计算和服务，并对外出租。

他们可能在 NP 完全问题方面取得重大突破，如分子模拟和物流优化问题。

这也可能意味着，对于那些负担得起量子计算机的人来说，TLS 就失灵了。

目前来看，量子计算可以为某些类型的问题带来重要的速度提升，但在短期内不会颠覆计算。

真正的影响可能是加速科学领域（物理、化学、生物模拟）的研究，然后反过来在其他地方取得突破性进展。

量子传送似乎更有可能带来对于大众而言更重要的突破——我们能不能在地球两端（及更远的地方）实现超光速通信？再说一遍，我认为，量子计算要对平民百姓产生影响还有很长的路要走。