【编者按】在IT圈有句名言：“活到老，学到老”。短短 6 字便道出技术发展速度之快。移动互联网、云计算、大数据、人工智能等技术革新在过去十年推动着时代巨轮不断向前迈步。接下来，我们不妨再放眼未来，又有哪些技术革新在等着我们呢？

作者 | Adrian Mouat

译者 | 弯月     责编 | 晋兆雨

内容提要：

• WASM 将无处不在：编译目标、部署目标、物联网、插件生态系统。（1～5年）

• Rust 将持续流行，并在未来几年内在 RedMonk 指数上超过 Go。（2～4年）

• Kubernetes 将遇到强劲的竞争对手。另外，Kubernetes 可能会使用 WASM 并提倡 GitOps 风格范式。（2～5年）

• 区块链生态系统即将崩溃，但是没有人知道确切的时间。可能多年后，我们会谈论“区块链的冬天”。（1～10年）

• 供应链安全会出现重大变革。在接下来的两年内，我们将会看到更多类似于 SolarWinds 的黑客攻击（可能已经发生了，只是我们不知道）。供应链工具将成为一个大幅增长的领域，但该行业广泛采用供应链工具（例如让每个人都使用 SBOM）的速度仍然非常慢。（2～10年）

• 无服务器将继续增长并逐渐成为主导范式。然而，随着人们逐步弄清楚如何根据新范式构建系统，无服务器领域也会经历更多的反弹和“失败”。（未来两年）

• 为了解决成本，很多公司会改回使用内部基础设施。（2～5年）这可能是最具争议/最不可能的观点。

• 某个人工智能将通过智能合约建立一个价值数十亿的公司，该公司会奴役整个人类（10～20年）。

• AI/ML 的进步有可能对多个行业造成大规模破坏。我不相信我们能够建立通用的人工智能，但会在特定领域取得巨大飞跃。有些工作岗位会被 AI 占据，比如卡车司机。至于哪些行业会受到影响，可能会出乎我们的预料（2～20年）。（虽然我不知道确切的时间，但这种变化会很突然。）

• 以 GPT3 为基础的 AI 助手将被广泛使用。艺术家、作家、开发人员、运营商、作曲家都将“雇佣” AI 助手。（1～4年）

编程语言

近年来，编程语言的发展似乎有一种向类型化语言转变的趋势，最引人注目的是 TypeScript 和 Rust。根据 GitHub Octoverse 最近的报告，如今大多数 JavaScript 框架都采用了 TypeScript，而且 TypeScript 也成为了排名前十的编程语言之一。 

Rust 的增长有目共睹，越来越多的底层软件都使用 Rust 编写，还有很多软件为了实现安全和速度移植到了 Rust。另外，Rust 也非常适合 WebAssembly (WASM) 生态系统，因为 Rust 可以编译成非常小的 WASM 二进制文件，这主要是因为 Rust 没有运行时或垃圾收集。对于现代语言来说，不包含垃圾收集是比较奇怪的现象，这是因为 Rust 不寻常的内存模型以及所有权和借用的概念。从 RedMonk 指数来看，考虑到推动 Rust 发展的因素，在未来几年内 Rust 很可能会超越 Go。 

从长远来看，我认为一些基于 Rust 概念（主要是内存模型和借用检查）的新语言将逐渐流行起来。同时还会将类型系统提升到一个新水平，我相信具有依赖类型的语言（例如 Idris）将从学术界跃升为行业内使用的流行语言。 

在开发微服务时，尤其是 Kubernetes，使用可以生成小型独立二进制文件的语言非常有优势。编译为 WASM 的语言也会变得更加重要，因为它们提供了各种 PaaS 以及边缘平台的访问。这两个因素可能会限制依赖 Erlang VM 的 Elixir 和 Gleam 等语言的增长。

Kubernetes 与部署平台

在接下来的 5 年中，Kubernetes 将持续增长。但是，如果 Kubernetes 不采取措施解决日益增长的复杂性，那么强大的竞争对手很快就会出现。如今这个阶段，运行和维护 Kubernetes 的难度都非常高，所以很多用户都采用了 GKE 等托管服务，或聘请 Giant Swarm 和 Container Solutions 等专业公司来管理 Kubernetes。即使是使用托管服务的公司也会寻求专业公司的支持。这不一定是坏事，因为在这些服务的帮助下，各个组织能够专注于核心业务，但这也意味着不愿为这些服务付费的用户也很容易被其他替代方案所吸引。 

请注意，Kubernetes 的复杂性不仅仅隐藏在幕后，甚至蔓延到了界面，并影响了用户。如今通过 `kubectl run` 设置并运行演示还算比较简单。但是运行生产应用，并弄清楚如何安全地公开应用，则需要了解大量的特性，不可避免地导致 YAML 文件膨胀，甚至超过大多数微服务的源代码。 

为什么会有这样的复杂性？很多都是发展的必然结果。刚开始的时候一切都很简单（最初的 Kubernetes 也相对比较简单），后来又添加了对某用例的支持。接着，我们意识到我们应该实现某个功能，另外还需重写某些功能，但与此同时还必须保持向后兼容。结果就会导致软件越来越复杂。这意味着新的竞争对手会出现并取代它，因为这些竞争对手没有历史包袱，可以从过去的成功和错误中吸取教训。 

换句话说，支持用例数量的增加会导致“80/20”问题：80% 的用户只使用 20% 的功能，但每个用户所使用的 20% 都不同。而删除某些功能却非常困难。新的竞争对手没有这个问题，他们可以围绕一套核心功能集构建新产品，并修复/避免其他问题。 

与往常一样，首先我们会看到一些小规模的变化。小公司和个人将避免使用 Kubernetes，转而采用更简单的解决方案，可能是某种开源 PaaS，也有可能使用 WASM。未来几年内，Nomad 的采用会大量增加。虽然刚开始的时候，人们会说：“可以，但是你不能大规模使用某个软件”，然而逐渐地这些问题都将得到解决，很快行业的另一场巨变就会降临。 

另一种可能性是 Kubernetes 将成为一种底层基础设施，其他一切功能都建立在其上。因此，小型项目可能会使用看似简单、精简的 PaaS（或类似 Knative 的 FaaS），但 PaaS 的底层却是 Kubernetes。考虑到 Kubernetes 所需的资源量以及 Kubernetes 的复杂性，我有点怀疑这种方式是否会被大规模采用。更简单、更有效的做法是将 Kubernetes 的精华提炼出来，并构建出新系统，我们看到了很多这方面的探索性工作，比如 k3s、KCP 和 badidea 等。附带说明一下，像 Backstage 和 Crossplane 这样的内部平台和工具将在大型组织中变得越来越普遍，而且即使 Kubernetes 的问题得到解决，它们也不会消失。 

将来无论发生什么，近期内 Kubernetes 都会以某种形式存在。它仍在快速发展，而且我们可以看到在未来几年内 Kubernetes 将产生很大的影响力。自定义操作器和 GitOps 将越来越普遍。一些创新 Kublet 的实现，比如Krustlet（支持将 WebAssembly 模块作为 Pod 运行）可能会受到关注。

WASM

WebAssembly 诞生已经很多年了，如今变得越来越普遍。论起 WASM 的普及原因，我们不禁回想起 Java 的口号：“一次编写，到处运行”。当初我们得知 Java 可以在任何地方运行，而且可完整地移植，这是一个巨大的成功，但远没有达到 Java 所宣称的水平：

● Java 非常慢且需要大量内存，因此无法在边缘设备中运行。

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

● 编写 JVM 的实现并非易事，它们之间的差异导致了“一次编写，到处调试”。

● 在浏览器中运行（小程序）需要安装一个插件。 

而如今 WASM 解决了所有上述问题。WASM 相对简单、高效且体积小。许多语言都可以编译为 WASM。主流浏览器已经有了成熟的实现。安全方面则更加出彩，WASI 项目可以让你精确地控制 WASM 可以做什么、可以读取什么输入、可以写入什么以及可以调用哪些内核。 

我们看到很多项目都采用 WASM 作为其插件系统，包括 Envoy 和 Ethereum。这种趋势只会扩大，因为你可以细致地控制允许插件访问的内容，同时允许用户以他们喜欢的任何语言编写插件，这些都非常合理。 

在许多用例中，WASM 都可以取代容器，我希望看到更多 WASM 与 Kubernetes 的集成，以 Krustlet 已实现的功能为基础。更有趣的是，通过 WASM 支持新的 PaaS 和 FaaS 平台，包括 Fastly compute 以及 Cloudflare workers。 

我们还将看到 WASM 在边缘设备中的使用，主要是因为其便携性和文件大小。 

话虽如此，WASM 依然面临着许多挑战。比如支持多种语言编译为 WASM。虽然很多语言都得到了支持，但支持的程度各不相同。目前排在第一位的是 Rust 语言，因为它具有良好的支持，而且可以创建相对较小的文件（正如前面所说 Rust 不包含垃圾收集和运行时）。此外，AssemblyScript （面向 WebAssembly 的 TypeScript）也很受欢迎。 

虽然 WASM 也支持其他语言（包括 Go），但文件大小往往会因垃圾收集器的实现或运行时功能而膨胀。其他语言的实现还处于起步阶段。 

很多重要的基础设施项目也是如此，比如 WASI，它定义了 WASM 与主机环境的交互方式。ByteCode Alliance 需要在快速构建生态系统方面发挥重要作用。

供应链安全

作为一个行业，我们在这方面的表现一直很糟糕（部分原因是安全行业的激励措施不够完善）。供应链没有被大量黑客攻击也算是幸运。将来我们会看到越来越多的组织意外运行“病毒”版本的软件，因为攻击者已经能够在某些阶段注入他们自己的软件，可能是编译阶段、分发阶段，甚至是更新期间。在某些情况下，还可能会被索要赎金，但我们将看到越来越多的高智商攻击，即先入侵某个组织，将其当作踏板入侵另一个组织。

为了解决这个问题，我们必须认真思考如何证明生产环境中运行的组件的来源。我们应该将 SBOM 与类似的元数据作为标准做法，并大量采用in-toto 和 Notary v2 等工具。GitOps 方法也可以发挥作用，即清晰地分离 CI 与部署之间的权限，并提供清晰地记录：谁修改了什么以及为什么。 

未来攻击的潜在影响已经引起了各国政府的注意，美国白宫已发布命令，要求审查美国政府的软件供应链，而英国则呼吁就供应链网络安全发表意见。希望人们共同努力改进标准实践，并建立有效防止攻击的工具生态系统。 

乐观的预测是，上述项目和方法（或其他类似的方法）得到大量采用；悲观的看法则是，越来越具有破坏性的供应链攻击将越来越频繁地发生。 

区块链与加密货币

虽然我认为区块链有其一定的用途，但该领域的绝大多数公司都会失败。我们没有充分的用例来证明投入到该生态系统中的资金是合理的。 

智能合约是一个我比较看好的领域。也许只是因为它让我想起了《渐速音》，人工智能可以在智能合约的支持下建立一个帝国吗？（智能合约会写什么？没错，WASM）。 

另一个潜在的用途是，前面提到的供应链安全领域，我们可以使用区块链来识别软件的来源吗？ 

至于加密货币，我非常希望看到小额支付方式与廉价（接近零成本）的国际汇款。我确信这是加密货币的承诺之一，但尚未兑现。虽然有关加密货币的项目有很多，但我不知道是否有可能实现。目前像 Coinbase 这样的公司，它们在类似服务方面收取的费用明显高于股票经纪人。 

我们必须停止工作量证明之类浪费资源的荒谬行为。从短期来看，唯一真正的替代方案似乎是权益证明，我们必须转向这样的模型。老实说，我希望比特币完蛋，但通过资金以及资金支持者的数量，可以看出短期内并不可能会发生这样的事情。

GitOps 与XX即代码

GitOps 的概念非常简洁，即将 Kubernetes 集群所需的状态存储在 Git 中。如果集群的实际状态有偏差，则进行协调（这隐藏了很多不同的可能性）。当你需要更改状态时，Git 存储库会被更新，并依次“协调”集群。这种做法的优势非常明显。我们能够通过克隆存储库来创建相同的集群，我们拥有完整的集群修改日志，而且还有完善的机制来讨论和批准更改（拉取请求）。然而，GitOps 的实现却没有那么容易，而且还有很多有竞争力的技术，包括 Kubestack、Flux 和 Argo CD。

我们已经将 GitOps 应用到了处于 Kubernetes 下层的技术栈，比如使用 Terraform 启动集群。随着微服务、无服务器、服务网格以及 SaaS 组件（如队列和数据库）的兴起，曾经有关应用程序的问题（比如将多个功能连接在一起），在某种程度上已经被推到了集群或基础设施层。显而易见，仅通过 YAML 文件不足以构建和定义集群。相反，我们需要成熟的编程语言。Pulumi 很早就看到了这一点并开始着手，但我认为我们可能会看到更多的迭代和潜在的解决方案。同样，WASM 可以让用户使用任意语言，因此也许能分一杯羹。在未来几年内，这一点会越来越明确，但我认为大量手写的 YAML 将被 CDK、Pulumi 等更易于阅读和推理的工具代替，YAML 和 CloudFormation 将成为编译目标。                 

无服务器与 FaaS

由于上述几点原因，Lambda 之类的 FaaS 解决方案将被大量采用。虽然这是必然的趋势，但这种方式不够整洁与简单。为了有效地使用 FaaS，我们需要建立不同风格的应用程序架构。队列和消息传递基础设施将成为必不可少的组件，在构建可靠的服务之前，我们必须从根本上理解它们的交互。以前可以通过数据结构和函数调用处理的功能，如今必须重新建模并考虑支持错误处理的分布式系统。该领域的最佳实践和设计模式需要一些时间才能转变成标准和常识。 

同时，我不清楚 Lambda 是否会成为这些问题的解决方案。Cloudflare 和 Fastly 的边缘计算 FaaS 产品非常优秀，通过 WASM 提供了出色的性能、扩展性以及语言灵活性。缺点是缺乏云提供商支持的基础设施，同时他们也在构建自己的 CDN（这其实抹杀了他们的优势）。所有这些产品都是专有的，因此许多公司都担心“被锁定”。出于这个原因，Knative 和 OpenFaaS 等开放替代方案很受欢迎，并进一步分散了市场。 

广义的无服务器（FaaS 与 SaaS 应用，比如数据库和队列等）将成为主导范式，但发展前景依然比较坎坷。在未来几年内，我们将看到一些成功的案例（“采用无服务器之后，我们每月可以节省1万美元”），也有一些灾难性的案例（“无服务器每月需要花费1万美元，因此我们放弃了”）。

人工智能与机器学习

我曾与从事智能合约的 AI 公司有所接触，对我来说，这个领域太不真实，更接近于科幻。为了更好地了解该领域，我们可以来看一看 GPT3 以及自动驾驶车辆的发展情况。AI 能写小说了吗？所有作者都可以将 AI 作为合著者或编辑了吗？美国有大量的卡车司机，十年内有多少司机会被 AI 所取代？有多少行业的多少工作岗位会被 AI 所取代？还是说 AI 只是一种炒作？ 

短期来看，最主要的变化似乎是基于 GTP3 的 AI “帮手”以及“自动补齐”，这方面的尝试将层出不穷。如果你正在写一篇文章，AI 可以帮助你自动补齐一个句子。如果你正在开发 Web 应用，AI 可以帮助你完成某个方法。如果你正在编写一首歌，创作一幅绘画，构思工程计划，那么 AI 也可以成为你的助手。而拒绝使用 AI 的人都会落后于时代。 

我们在来看一看云计算的发展，这也反映出了 AI 运维的发展，所谓 AI 运维指的是通过机器学习分析应用程序的日志和遥测数据，以识别问题并找出有待改进的领域。 

我不相信我们能够在短期内开发出通用的人工智能，因此重大变化可能仅限于各个行业和具体用例。但这些部门的变化可能仍然是一场彻底的革命。这些变化很可能会突然发生，而只有少数掌握了该技术的公司会从中受益，从而进一步加剧社会的经济分裂。 

我担心的是出现我们始料未及的可能性，因为 AI 的变化几乎可以在一夜之间发生。科幻作家经常谈论“奇点”，从广义上说，“奇点”指的是当人工智能跨越某个点时，变化就会加速，超出人类的预测或认知水平。有些观点可能略显夸张，但我绝对相信人工智能将产生我们未曾预见的重大社会影响。

混合技术的崛起

目前，内部基础设施、裸金属和混合市场上有很多来自新老厂商的活动。首先声明，我不是特别关注这个部门，因此我的一些观点可能并不正确。 

总的来看，公共云是大势所趋，但我相信我们正在向内部基础设施和混合技术的采用迈进。戴尔和HPE等传统硬件公司可能在此过程中犯了很多错误，但是似乎他们都在向着“XX即服务”的模式迈进，即消费者按使用量付费。起初，似乎这种方式与本地硬件背道而驰，但据说，供应商会提供容量过剩的硬件，并保证在需要时快速交付更多硬件。该模型的优点在于平衡承诺、资本支出和运营支出。你想降低每个实例每月的成本吗？那么请签署 5 年的合约和/或预先购买硬件。在确定业务模型时想要更灵活的模型？你可以签订 1 年合同，只不过每个实例的费用更高。 

HPE 的 GreenLake 和戴尔的 Project Apex 就采用了这类模型。鉴于 IBM 最近的收购以及现有的产品和解决方案，我认为他们将在市场上采取类似的措施。Nutanix 显然也介入了这一领域，他们提供了云资源和/或本地硬件的软件控制平面。控制平面的重要性就无需过分强调了，只有在能够轻松集成混合资源以及维护基础设施的情况下，该模型才能发挥作用。新加入的 Oxide 大概也计划在这方面进行一些创新，他们提供了更好的硬件与管理程序的各种软件层之间的集成。另外，请注意，这完全不同于 Equinix 和 Scaleway 等裸金属和数据中心公司目前提供以及正在建设的产品，不同之处在于对于“内部基础设施”的理解，是在自己的数据中心运行的设施，还是在其他数据中心的硬件？我必须拥有这些硬件，还是可以租用？ 

在后台，云提供商和芯片制造商之间还有一些有趣的动态。云提供商希望将芯片商品化，这样每隔几年他们就可以快速廉价地更换一次芯片。而芯片制造商则希望尽可能多地向云提供商销售芯片，同时保持对市场的控制。为了满足各种客户群的不同需求，芯片制造商可能会支持 HPE 和戴尔，以及任何能够促进多样化内部基础设备和边缘计算平台的举措。相比之下，云提供商已经开始构建自己的定制芯片并进军本地市场了。 

此外，云提供商还会与 Cloudflare 和 Fastly 等 CDN 提供商发生冲突。这两家公司都已开始提供无服务器计算服务，这些服务利用其数据中心尽可能地拉近与客户的距离。所谓近水楼台先得月，因此他们在速度和成本方面都占据主要优势。他们最大的缺点是无法访问 AWS 等提供的大量功能，通常你只能获得数据存储和计算服务，仅此而已。虽然我认为这些服务会大幅增长，但云提供商为了反击也在积极地向 CDN 领域扩展。 

鉴于潜在的成本节约以及避免“被锁定”，我们将看到有些公司将退回到内部基础设施与混合方案。云将继续占据主导地位，尤其是在创业领域，但成熟的公司会衡量他们能否节省大量的运营成本。那么，究竟谁能成为这场运动的最大赢家呢？传统硬件供应商、裸金属与数据中心供应商、边缘计算供应商、云供应商还是管理平面软件供应商？

量子计算

量子计算也是备受关注的一个领域，尽管我对该领域的了解也很有限。 

鉴于量子计算需要真空和接近绝对零度的温度，似乎短期内我们不太可能看到量子笔记本电脑。事实上，量子计算机的成本过高，只有大公司和政府才能负担得起。然而，公众仍然有机会接触量子计算，主流云提供商都宣布了对量子计算的研究以及量子计算的出租服务。量子计算可能给NP完备问题带来重大突破，例如分子模拟和优化逻辑问题等。这也可能意味着，只要有能力负担量子计算机，TLS等加密的破解就不是问题。目前看来，量子计算将加速某些类别的问题，但在短期内并不会颠覆计算。量子计算真正的影响在于加速科学领域的研究（物理、化学和生物的模拟），而这反过来可能会引发其他领域的突破性进展。 

量子隐形传态似乎更有可能带来影响到公众的重大突破，我们能否在地球两端（以及更远的地方！）之间实现比光速更快的高带宽通信？同样，我认为量子技术要想真正能够影响到大众，还有很长一段路要走。

原文链接：https://blog.container-solutions.com/10-predictions-for-the-future-of-computing

声明：本文由CSDN翻译，转载请注明来源。 

☞腾讯宣布捐赠1亿元驰援河南；苹果回应iPhone 安全隐患；贝索斯完成10分钟太空之旅|极客头条
☞10年IT老兵给新人程序员的几点建议
☞“我想再当一次 CEO，所以我离开了 IBM”

CSDN

成就一亿技术人

3022篇原创内容

公众号