【翻译】对计算机未来的10个预测或；我们的首席科学家的无稽之谈

admin管理员组

文章数量:1566681

TLDR；

• WASM将无处不在：编译目标、部署目标、物联网、插件生态系统。这已经在发生了!(
• 1-5年）
• Rust将继续流行，根据RedMonk的指数，在未来几年将超过Go。(
• 2-4年）
• 将出现一个严重的Kubernetes的对手。如果它使用WASM并鼓励GitOps风格的范式，则可获得奖励。(
• 2-5年）
• 区块链生态系统将内爆，但谁知道什么时候。它可能会悄悄发生，多年后我们会谈论 "区块链的冬天"。谁知道呢？(
• 1-10年）
• 供应链安全将是大问题。在未来2年内，会有更多像SolarWinds那样规模的黑客攻击（可能已经有了，只是我们不知道）。供应链工具（我不愿意说 "解决方案"）将是一个大的增长领域，但该行业在实现广泛接受方面仍然很缓慢（例如，让每个人都使用SBOMs）。(~2-10年)
• 几乎没有预测，但无服务器将继续增长，并将慢慢成为主导模式。(10年？Kubernetes有很大的发展空间。) 然而，它也会经历更多的反弹和 "失败 "的故事，因为人们在努力找出如何为新范式架构系统。(未来2年)
• 我们将开始看到公司为了节省成本而部分地回到内部部署。(
• 2-5年）这可能是最有争议/最不可能的想法，
• 人工智能有可能利用智能合约建立一个数十亿美元的公司，从而奴役整个人类。(
• 10-20年）
• 好吧，希望不会，但人工智能/ML的进步有可能对多个行业产生大规模的破坏。我不相信我们会发展出一种普遍的人工智能，而是会在特定的领域中实现大的跳跃。这可能涉及到工作被大规模消灭，例如卡车驾驶。哪些行业会受到影响可能会让我们感到惊讶。(
• 2-20年）（我不知道什么时候，但变化将是突然的。）
• 在同一主题下，GPT3风格的帮助器--有效地自动完成所有事情--将被广泛使用。艺术家、作家、开发者、操作者、作曲家都将使用它们。(1-4年)

编程语言

我先说一下，我不是一个编程语言专家。这是一个我觉得我应该了解更多的领域，并且很想多玩玩！

近年来，似乎有一个向类型化语言的摇摆--也许最明显的是TypeScript和Rust。TypeScript现在被用于大多数的JavaScript框架中，根据最近的 GitHub Octoverse报告，它是十大语言之一。 特别是Rust，我认为它将会有很大的发展，越来越多的底层软件会用Rust编写，在 某些情况下会移植到Rust，以达到安全和速度的目的。它也很适合WebAssembly（WASM）生态系统，因为它可以编译成一个小的WASM二进制文件，主要是由于缺乏运行时或垃圾收集（GC）。没有GC在现代语言中几乎是一种奇怪的现象，这是由于Rust不寻常的内存模型以及 所有权和借用的概念。从 RedMonk指数来看，考虑到推动Rust发展的因素，Rust很可能在未来几年内超过Go的受欢迎程度。

从长远来看，我认为我们会看到以Rust的概念为基础的新语言（主要是内存模型和借贷检查）以及更高级别的功能变得流行。在类型系统方面，我相信具有依赖类型的语言（如Idris）将从学术界（或业余语言）跃升为工业界使用的流行语言。

在开发微服务时，特别是为Kubernetes，使用能够产生小型独立二进制文件的语言是有益的。编译成WASM的语言也可能会变得更加重要，因为它们将提供对各种PaaS和边缘平台的访问。这两个因素可能会限制Elixir和Gleam等语言的发展，这些语言依赖于Erlang虚拟机。（请注意，LUMEN等项目可能会证明我在这里完全错了）。

Kubernetes和部署平台

在未来5年，Kubernetes（也称为k8s）将继续增长。但是，除非它做一些事情来解决不断膨胀的复杂性，否则我们将开始看到严重的竞争对手。我们正在进入这样一个阶段：运行和维护Kubernetes已经足够复杂，以至于用户正在转向GKE这样的管理服务，或者雇佣Giant Swarm和Container Solutions这样的专业公司来处理Kubernetes。即使是使用管理服务的公司也会向专业公司寻求支持。这不一定是件坏事--这些服务使组织能够专注于核心业务--但它确实意味着那些不愿意为这些服务付费的用户将被更简单的替代方案所吸引。

值得注意的是，复杂性并不仅仅隐藏在引擎盖下。它正溢出到界面上，影响着用户。在 "kubectl run "上进行黑客攻击并得到一个演示，仍然相当容易。但是，运行生产应用和弄清楚如何安全地暴露它们需要了解大量不同的功能，这不可避免地导致YAML文件比大多数微服务源代码还要长。

为什么会有这样的复杂性？很大程度上是因为进化。我们从简单的东西开始（在Kubernetes的情况下是相对简单的），然后增加对用例x的支持。然后我们意识到如果我们做z会更好，于是重写东西，但必须保持向下兼容。这就导致了问题的复杂性，而这并不是问题的内在原因（意外的复杂性）。意味着一个新的竞争者可以出现并取代它，因为他们没有所有的历史包袱，可以从过去的成就和错误中学习。

换

个说法，增加支持的用例数量

导致

了"80/20 "问题--80%的用户只使用20%的功能，但每个人使用不同的20%。剥夺功能是困难的。新的竞争者没有这个问题，他们可以围绕一个较小的核心功能集建立一个新的产品，并可能修复/避免其他问题（100英镑说它不使用YAML）。

与以往一样，我们将首先看到小规模的变化。小公司和个人将避免使用k8s，而选择更简单的解决方案，可能是某种开源的PaaS，并可能利用WASM。Nomad可能会在未来几年开始获得大量的吸收。一开始人们会说 "是的，但你不能大规模地使用X"，但慢慢地，问题会得到解决，行业的另一次巨变将来临。

另一种可能性是，Kubernetes成为一个底层的基础设施层，被其他一切建立在其上。因此，小项目可能会使用看似简单、精简的PaaS（或像Knative这样的FaaS），但该PaaS将是引擎盖下的K8s。由于Kubernetes需要大量的资源，而且Kubernetes的复杂性有 "暴露 "的趋势，我有点怀疑这是否会实现大规模的采用。将k8s的最佳部分提炼到一个新的系统中可能更简单、更有效--我们在这里看到很多探索性的工作，比如k3s、KCP和badidea。

从

侧面看，像Humanitec、Backstage和Crossplane这样的内部平台和工具将在大型组织中变得普遍，即使Kubernetes消失了，这也不会消失。

(对于那些对构建Kubernetes杀手感兴趣的人，也许值得看看Prolog和这个讨论。)

无论发生什么，Kubernetes将以某种形式长期存在于我们身边。它仍在快速发展，我们可以看到可能会影响未来几年的技术。自定义运营商和GitOps将成为普遍现象。一些创新的Kublet实现，如Krustlet（支持将WebAssembly模块作为pod运行）可能会开始受到关注。

WASM

WebAssembly已经存在了几年，但现在可能已经准备好变得

无处不在

。要理解为什么，最简单的方法是回想一下（假设你有一定的年纪！）Java最初的口号。"一次编写，随处运行"。我们被告知，Java将在任何地方运行，并且是完全可移植的。这是一个巨大的成功，但远远没有达到声称的水平。为什么没有呢？嗯：

• 它是（或至少被认为是）慢的，而且内存不足。
• 你需要学习Java（现在有更多的JVM语言，但以前的选择是有限的）。
• 编写JVM实现并非易事，它们之间的差异导致了 "只写一次，到处调试 "的诅咒。
• 在浏览器中运行（小程序）需要安装插件。

那么，WASM解决了所有这些问题。它相对简单、高效、小巧。许多语言都可以被编译到WASM中。主要的浏览器已经有了成熟的实现。安全方面的故事是令人信服的--WASI项目让你准确地控制WASM被允许做什么，它可以从哪些输入读取，它可以写入哪些内容，以及它可以进行哪些内核调用。

我们已经看到多个项目采用WASM作为其插件系统，包括Envoy和Ethereum。这只会扩大，因为它非常有意义；你可以在细粒度上控制允许插件访问的内容，同时允许用户用他们喜欢的任何语言编写插件。

WASM在很多用例

中

取代了容器，我希望看到更多与Kubernetes的整合，在Krustlet已经展示的承诺基础上。更有趣的是使用WASM来支持新的PaaS和FaaS平台，包括Fastlycompute@edge和Cloudflare workers。

我们还将看到它在边缘的使用，主要是由于可移植性和磁盘大小。

尽管如此

，仍然存在挑战。我在上面写到，有支持将多种语言编译到WASM。这是真的，但支持是不平等的。Rust似乎是排名第一的语言，因为它有很好的支持，而且创建的文件相对较小（由于前面提到的缺乏GC和运行时）。AssemblyScript--适合WebAssembly的TypeScript的一个版本--也很受欢迎。

虽然对包括Go在内的其他语言有很好的支持，但文件大小往往会因为垃圾收集器的实现或运行时特性而膨胀。其他语言的实现往往还处于起步阶段。

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

供应链安全

我们作为一个行业在这方面一直很糟糕（部分原因是安全行业的激励机制被打破）。令人惊讶的是，这并没有导致更多的攻击。我们将看到越来越多的案例，组织意外地运行 "中毒 "版本的软件，因为攻击者已经能够在某个阶段注入他们自己的软件--无论是在编译、分发还是更新期间。在某些情况下，这将导致令人尴尬的加密赎金，但我们将开始看到越来越多的 "智能 "攻击，其中一个组织被入侵作为另一个组织的垫脚石（如SolarWinds）。

这个问题的答案是开始考虑如何证明生产中运行的组件的来源。当务之急是让SBOM和类似的元数据成为标准做法，让in-toto和Notary v2等工具成为普遍做法。下面描述的GitOps方法也可以发挥一定的

作用

，它将CI和部署之间的权限干净地分开，并提供谁改变了什么以及为什么改变的清晰线索。

未来攻击的潜在影响足够严重，以至于政府开始觉醒并注意到--白宫已经发布命令，审查美国政府的软件供应链，英国已经发布

了

关于供应链网络安全的意见征集。希望这是一个协调努力的开始，以改善标准做法，并建立一个有效防止攻击的工具生态系统。

这里乐观的预测是，这些项目和方法（或等价物）得到大量的吸收。悲观的预测是他们没有，我们看到越来越频繁、越来越有破坏性的供应链攻击。

区块链和加密货币

我很抱歉，但我认为区块链有其用途，该领域的绝大多数公司都会失败。只是没有足够的可行的用例来证明生态系统中的资金量是合理的。如果你在这个领域，我希望你卖的是黑桃。

有一个领域可以证明我错了，那就是智能合约。也许这只是因为它让我想起了Accelerando--我们能否让人工智能在智能合约的基础上建立一个帝国？

(

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

关于 "加密货币"，我希望看到一种真正的方法来进行小额支付和廉价（接近零成本）的国际汇款。我确信这是加密货币的承诺之一，但它还没有被兑现。评估加密货币的无数项目是如此困难，我不知道这是否有可能实现。

目前，

我们有像Coinbase这样的公司，他们对类似服务的收费比例明显高于股票经纪人。

我们必须停止工作证明 所带来的可笑的资源浪费现象。在短期内，唯一真正的替代方案似乎是权益证明，我们必须转向这样一种模式。我真诚地希望比特币走到尽头，但资金的数量和支持者的数量意味着这在短期内可能不会发生。

关于NFTs，我再次表示怀疑，但喜欢今年早些时候的这篇文章。

GitOps和x-as-code

GitOps的想法是非常干净和简单的。将Kubernetes集群的所需状态存储在Git中。如果集群的实际状态有偏差，就进行调和（这隐藏了很多不同的可能性）。当你需要改变状态时，Git repo会被更新，集群也会被反过来 "调和"。这样做的好处是非常棒的：我们应该可以通过克隆 repo 来调出一个相同的集群，我们有一个所有改动的完整日志，还有一个讨论和批准改动的既定机制（拉动请求）。然而，实施GitOps并不像听起来那么容易，已经有很多竞争性技术--包括Kubestack、Flux和Argo CD。

我们已经在Kubernetes下面的堆栈中应用GitOps，比如使用Terraform来建立集群。随着微服务、无服务器、服务网和SaaS组件（如队列和数据库）的兴起，曾经的应用问题（如将功能连接在一起）在某种程度上已经被推到了集群或基础设施层。这方面的明显推论是，YAML文件已经不足以构建和定义集群了。相反，我们需要全面的编程语言。Pulumi很早就看到了这一点，并抓住了它，但我认为我们可能会看到更多的迭代和潜在的解决方案。同样，WASM在允许用户带来他们自己的编程语言方面可能会起到一定的作用。未来几年将澄清这一点，但我预计很多手写的YAML将被CDK、Pulumi等取代，它们更容易阅读和推理--YAML和CloudFormation实际上将成为编译目标。

无服务器和FaaS

上述观点导致了FaaS解决方案的采用，如Lambda。这肯定会发生，但这并不是一些支持者似乎认为的那种干净而简单的变化。有效地使用FaaS需要一种不同的应用程序架构风格。队列和消息传递基础设施成为重要的组件，在可靠的服务被建立之前，必须从根本上理解它们的互动。以前可以用数据结构和函数调用来处理的事情，必须被改造，并作为一个支持错误处理的分布式系统来考虑。这个领域的最佳实践和设计模式需要一些时间才能成为标准化的常识。

同时，我也不清楚Lambda是否会在这里占据全部。来自Cloudflare和Fastly的边缘计算FaaS产品是引人注目的，通过WASM提供令人印象深刻的性能和扩展性以及语言灵活性。缺点是他们缺乏云供应商的支持性基础设施，而云供应商同时也在建立自己的CDN，以抵消他们的优势。所有这些产品都因其专有性而受到影响，这使许多公司产生了 "锁定 "的想法。

广义的无服务器（包括FaaS和SaaS应用，如数据库和队列）将成为主流模式，但其发展道路可能比我们预期的要艰难。未来几年，我们将看到成功的故事（"我们通过迁移到无服务器，每月节省了1万块钱"）和灾难的故事（"我们在无服务器花费了每月1万块钱后放弃了它"）。

人工智能和机器学习

这是让我害怕的小丑。我提到了运行智能合约的人工智能公司，但这确实是我心中的科幻迷而不是实用主义者。我们可以通过看看GPT3（原始论文）能做什么，以及我们在自动驾驶卡车和汽车方面的情况来更好地了解正在发生的事情。我是否能够写出一篇具有乔治-奥威尔文章质量的博文？所有的作者都会开始使用人工智能作为共同作者和编辑吗？卡车驾驶是美国最大的就业来源之一--在这十年中，有多少人将被人工智能取代？究竟有多少行业的多少工作会被取代？(对于一些更多的--和更好的研究--预测，请看Sam Altman的文章和采访)。

在短期内，主要的变化似乎是基于GTP3的人工智能 "助手 "和 "自动完成"，以及它的后继者将无处不在。如果你在写博客，它将帮助完成你的句子。如果你正在开发一个网络应用，它将完成你的方法。如果你在写一首歌，画一幅画，勾画一个工程计划，"帮助 "就在身边。我们中那些回避这种帮助的人很可能会被甩在后面。

把事情带回到云计算的具体发展上，这也反映了AI Ops的增长--机器学习被用来分析运行中的应用程序的日志和遥测数据，以确定问题和改进的领域。

我不相信我们会在短期内开发出一个通用的人工智能，所以剧烈的变化可能仅限于各个行业和使用场景。但这些行业的变化仍可能是一场彻底的革命。这些变化很可能是突然发生的，利益将归于少数拥有技术的公司，进一步加剧社会的经济分裂。

我的恐惧来自于知道我甚至还没有想象到一些可能性，而随着人工智能的变化几乎可以在一夜之间发生。科幻作家经常谈论 "奇点"--广义上的想法是，当人工智能跨越某个点时，变化将加速，人类将无法预测或跟上进展。对此有些观点可能是夸张的，但我绝对相信，人工智能将产生我们未曾预见的重大社会影响。

混合动力的崛起

目前，

在内部部署、裸机和混合动力市场上似乎有很多活动，既有新玩家也有老玩家。这不是我密切关注的领域，所以这可能会偏离目标，但我还是要继续胡说八道。

从外面看，一切都在不可避免地走向公有云，但我相信我们正处于向内部部署和混合的摆动开始。像戴尔和HPE这样的传统硬件公司可能在这一路上犯了很多错误，但他们似乎都在向*aaS模式发展，即消费者为他们使用的东西付费。乍听之下，这与拥有内部硬件不相容，但据推测，这意味着供应商将以过剩的能力运送硬件，并保证在需要时快速交付更多的硬件。这种模式的一个有趣之处在于它允许平衡承诺、CAPEX和OPEX。想降低每个实例的每月成本吗？同意5年的合同和/或预先购买HW。当你弄清楚你的商业模式时，想要一个更灵活的模式？

HPE的GreenLake和戴尔的Project Apex就是这种模式的典范

。

鉴于IBM最近的收购和现有的产品和解决方案，可以猜测他们会在市场上做出类似的举动。Nutanix显然也在这个领域，提供一个软件控制平面，支持云资源和/或内部硬件。控制平面的重要性怎么强调都不为过--只有在能够轻松整合混合资源和维护基础设施的情况下，这种模式才能发挥作用。新来的Oxide公司大概也有一些这方面的创新计划，通过在硬件和管理程序的各种软件层之间提供更好的整合。还值得指出的是，这与Equinix和Scaleway等裸机和数据中心公司目前提供的和正在建设的东西相差无几--区别也许在于我们所说的 "预制 "是什么意思？它是在我自己的数据中心运行的东西，还是也可以是我在别人的数据中心的硬件？ 我必须拥有这些硬件，还是可以租用？

在此背景下，我们在云供应商和芯片制造商之间也有一套有趣的动态关系。云供应商希望将芯片商品化，以便每隔几年就能廉价快速地更换。芯片制造商希望确保他们尽可能多地卖给云供应商，同时保持对市场的控制。为了保留有不同需求的客户群，芯片制造商可能会支持HPE和戴尔的行动，以及任何促进多样化的内部和边缘计算平台的行动。相比之下，云供应商已经开始建立自己的定制芯片，并向 企业内部市场推进。

云供应商还与Cloudflare和Fastly等CDN供应商进行了斗争。这两家公司都已经开始提供无服务器计算服务 ，利用他们的数据中心尽可能地靠近客户运作（一种 "边缘 "计算的形式）。由于离最终用户更近，在速度和--似乎--成本方面都有很大的优势。他们最大的缺点是，他们无法获得AWS等提供的大量功能--通常你会得到一个数据存储和计算服务，除此之外就没有了。虽然我预计这些服务会有巨大的增长，但云供应商正在通过积极扩展CDN 空间进行反击。

鉴于潜在的成本节约和避免 "锁定"，我们将开始看到一些公司 "回归 "到内部/混合型。云将继续占主导地位，特别是在初创企业领域，但成熟的公司将寻找他们是否能显著节省运营成本。也许更困难的问题是，谁将成为这场运动的最大赢家--传统的硬件供应商、裸机和数据中心供应商、边缘计算供应商、云供应商或管理平面软件供应商？

量子的脚注

量子计算是另一个领域，你可以把我知道的一切写在针头上，然后戳进我的眼睛。

鉴于量子计算涉及真空和接近绝对零度的温度，我们似乎不太可能很快得到量子笔记本电脑。事实上，成本是如此之高，只有大型企业和政府能够负担得起自己的量子计算机。然而，这并没有将公众与量子计算隔绝开来--主要的云计算供应商都已经宣布了对量子的研究和服务的出租。他们在NP完整问题上提供了潜在的巨大突破，如分子模拟和优化物流问题。这也可能意味着，对于那些有能力的人来说，TLS被打破了。目前看来，量子计算将为某些类别的问题提供重要的速度提升，但在短期内不会颠覆计算。真正的影响可能是加速科学领域的研究（想想物理、化学和生物模拟），这可能反过来导致其他领域的突破。

量子传送似乎更有可能导致对公众具有根本意义的重要突破--我们是否可以在地球的两端（甚至更远！）实现比光速

更

高的通信？同样，我认为我们离影响公众的技术还有一段距离。

本文标签： 无稽之谈首席科学家未来计算机