对计算机未来的10个预测
微wx笑
2021-07-31【见闻】
6
0关键字：
计算机 未来 预测
WASM 将无处不在：编译目标、部署目标、物联网、插件生态系统。这已经发生了！(1-5 年)
Rust 将继续流行，并将在未来几年内通过 RedMonk 指数超过 Go。(2 - 4 年)
Kubernetes 的一个重要竞争对手将会出现。如果它使用 WASM 并鼓励 GitOps 风格范式，则可以加分。（2-5 年）
区块链生态系统会崩溃，但谁知道什么时候。可能它会悄悄发生，多年后我们将谈论“区块链冬天”。谁知道？（1-10 年）
TLDR；?
WASM 将无处不在：编译目标、部署目标、物联网、插件生态系统。这已经发生了！(1-5 年)
Rust 将继续流行，并将在未来几年内通过 RedMonk 指数超过 Go。(2 - 4 年)
Kubernetes 的一个重要竞争对手将会出现。如果它使用 WASM 并鼓励 GitOps 风格范式，则可以加分。（2-5 年）
区块链生态系统会崩溃，但谁知道什么时候。可能它会悄悄发生，多年后我们将谈论“区块链冬天”。谁知道？（1-10 年）
供应链安全性会很大。在接下来的大约 2 年内，将会有更多像 SolarWinds 那样的黑客攻击（可能已经发生了，我们只是不知道）。供应链工具（我不敢说“解决方案”）将是一个很大的增长领域，但该行业在实现广泛采用（例如让每个人都使用 SBOM）方面仍然很慢。（~2-10 年）
几乎没有预测，但无服务器将继续增长并慢慢成为主导范式。（10 年？Kubernetes 有很多动力。）然而，随着人们努力弄清楚如何为新范式构建系统，它也会经历更多的反弹和“失败”故事。（未来两年）
我们将开始看到公司部分地回到本地以节省成本。（2-5 年）这可能是这里最具争议/最不可能的想法。
人工智能利用智能合约建立一个价值数十亿的公司的可能性很大，这奴役了整个人类。(10-20 年)
好吧，希望不是，但是 AI/ML 的进步可能会对多个行业造成大规模破坏。我不相信我们会发展出通用的人工智能，而是会在特定领域取得巨大飞跃。这可能涉及大量工作，例如卡车驾驶。哪些行业受到影响可能会让我们感到惊讶。（2-20 年）（我不知道什么时候，但变化会很突然。）
在同一主题上，GPT3 风格的助手——有效地自动完成所有事情——将被广泛使用。艺术家、作家、开发人员、运营商、作曲家都将使用它们。(1-4 年)
编程语言
我先声明我不是编程语言专家。这是我觉得我应该了解更多并且很想玩更多的领域之一！
首先我要说我不是一个编程语言专家。这我觉得我应该更了解自己的领域，而且我很乐意和这些人一起玩！
近年来，似乎有一种转向类型化语言的趋势——也许最引人注目的是 TypeScript 和 Rust。根据最近的GitHub Octoverse 报告， TypeScript 现在在大多数 JavaScript 框架中使用，并且是排名前 10 的语言之一。特别是 Rust，我认为会看到很多增长，越来越多的低级软件被编写，在某些情况下移植到Rust 以实现安全和速度。它也非常适合 WebAssembly (WASM) 生态系统，因为它可以编译为一个小的 WASM 二进制文件，这主要是由于缺少运行时或垃圾收集 (GC)。没有 GC 在现代语言中几乎是一种奇怪的现象，这是由于 Rust 不寻常的内存模型以及所有权和借用的概念。看着RedMonk 指数，考虑到推动 Rust 发展的因素，Rust 很可能在未来几年内超过 Go。
从长远来看，我认为我们会看到基于 Rust 概念（主要是内存模型和借用检查）的新语言变得流行起来。将类型系统提升到一个新的水平，我相信具有依赖类型的语言（例如Idris）将从学术界（或业余语言）跃升为行业内使用的流行语言。
在开发微服务时，尤其是 Kubernetes，使用一种可以生成小型独立二进制文件的语言是有益的。编译为 WASM 的语言也可能变得更加重要，因为它们将提供对各种 PaaS 和边缘平台的访问。这两个因素可能会限制依赖 Erlang VM 的Elixir和Gleam等语言的增长。（请注意，像LUMEN这样的项目可能在这里证明我完全错了。）
Kubernetes 和部署平台
在接下来的 5 年中，Kubernetes（也称为 k8s）将继续增长。但除非它采取措施解决日益增长的复杂性，否则我们将开始看到严重的竞争对手。我们正在进入运行和维护 Kubernetes 足够复杂的阶段，以至于用户转向 GKE 等托管服务或聘请 Giant Swarm 和 Container Solutions 等专业公司来管理 Kubernetes。即使是托管服务的公司也会寻求专业公司的支持。这不一定是件坏事——这些服务使组织能够专注于核心业务——但这确实意味着不愿为这些服务付费的用户将被更简单的替代方案所吸引。
值得注意的是，复杂性不仅仅隐藏在幕后。它正在蔓延到界面并影响用户。在 `kubectl run` 上进行 hack 并启动并运行演示仍然相当容易。但是运行生产应用程序并弄清楚如何安全地公开它们需要了解大量不同的特性，这些特性不可避免地导致 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。附带说明一下，内部平台和工具，如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 平台，包括 Fastly compute@edge和Cloudflare workers。
我们还将看到它在边缘使用，主要是由于便携性和磁盘大小。
话虽如此，仍然存在挑战。我在上面写过关于支持将多种语言编译为 WASM。这是事实，但支持并不相等。从远处看，Rust 似乎是排名第一的语言，因为它有很好的支持并且创建的文件相对较小（由于前面提到的 GC 和运行时的缺失）。AssemblyScript - 适用于 WebAssembly 的 TypeScript 版本 - 也很受欢迎。
虽然对包括 Go 在内的其他语言有很好的支持，但文件大小往往会因垃圾收集器实现或运行时功能而膨胀。其他语言实现往往还处于起步阶段。
很多重要的基础设施项目也是如此，比如WASI，它定义了 WASM 如何与宿主环境交互。该字节代码联盟将需要快速构建出生态系统中发挥重要作用。
供应链安全
作为一个行业，我们在这方面一直很糟糕（部分原因是安全行业的激励措施不健全）。令人惊讶的是，它并没有导致更多的攻击。我们将看到越来越多的组织意外运行“中毒”版本的软件，因为攻击者已经能够在某个阶段注入他们自己的软件——无论是在编译、分发还是更新期间。在某些情况下，这会导致令人尴尬的加密赎金，但我们将开始看到越来越多的“智能”攻击，其中一个组织受到损害，作为另一个组织（ala SolarWinds）的垫脚石。
这个问题的答案是开始思考我们如何证明在生产中运行的组件的来源。SBOM和类似的元数据必须成为标准做法，in-toto和Notary v2等工具变得司空见惯。下面描述的 GitOps 方法也可以发挥作用，通过在 CI 和部署之间干净地分离特权，以及提供谁改变了什么以及为什么改变的清晰线索。
未来攻击的潜在影响已经严重到足以让各国政府开始警醒和注意——白宫已发布命令审查美国政府的软件供应链，英国已发出呼吁就供应链网络安全发表意见。希望这是改进标准实践和建立有效防止攻击的工具生态系统的协调努力的开始。
这里的乐观预测是，这些项目和方法（或等价物）得到了大量采用。悲观的是他们没有，我们看到越来越频繁、越来越具有破坏性的供应链攻击。
区块链和加密货币
对不起兄弟们，虽然我认为区块链有其用途，但该地区的绝大多数公司都会失败。没有足够的可行用例来证明生态系统中的资金数量是合理的。如果你在那个地区，我希望你卖黑桃。
一个可以证明我错的领域是智能合约。也许这只是因为它让我想起了Accelerando——我们可以让人工智能在智能合约的支持下建立一个帝国吗？（智能合约会写什么？你猜对了 - WASM。）
另一个潜在的用例是在前面提到的供应链安全领域——我们可以使用区块链来识别软件的来源吗？
更一般地说，在“加密”方面，我很想看到一种真正的方式来进行小额支付和廉价（接近零成本）的国际汇款。我确信这是加密货币的承诺之一，但尚未兑现。评估加密货币中的无数项目非常困难，我不知道这是否有可能实现。目前，我们有像 Coinbase 这样的公司，他们对类似服务收取的百分比明显高于股票经纪人。
我们必须停止工作量证明带来的荒谬的资源浪费。从短期来看，唯一真正的替代方案似乎是权益证明，我们必须转向这样的模型。老实说，我希望比特币结束，但资金的数量和资金支持者的数量意味着这在短期内可能不会发生。
关于 NFT，我再次持怀疑态度，但很喜欢今年早些时候的这篇文章。
GitOps 和 x-as-code
GitOps 的想法非常干净和简单。将 Kubernetes 集群所需的状态存储在 Git 中。如果集群的实际状态有偏差，则进行协调（这隐藏了很多不同的可能性）。当您需要更改状态时，会更新 Git 存储库并依次“协调”集群。有益的副作用是惊人的：我们应该能够通过克隆 repo 来创建一个相同的集群，我们拥有所有更改的完整日志，以及用于讨论和批准更改（拉取请求）的既定机制。然而，实施 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（原始论文）可以做什么以及我们在自动驾驶卡车和汽车上的位置，我们可以更好地了解正在发生的事情。我能写出具有乔治奥威尔论文质量的博客文章吗？所有作者都会开始使用人工智能作为共同作者和编辑吗？卡车驾驶是美国最大的就业来源之一——十年内有多少人会被人工智能取代？多少行业的多少工作岗位将被取代？（有关更多 - 更好研究 - 的预测，请查看 Sam Altman 的文章和采访.) 或者这只是另一个炒作周期？
短期来看，主要的变化似乎是基于GTP3的AI“帮手”和“自动完成” ，其后继者将无处不在。如果您正在写博客，它将有助于完成您的句子。如果您正在开发 Web 应用程序，它将完善您的方法。如果您正在写一首歌、画一幅画、勾画工程计划，“帮助”就在手边。我们这些避开此类帮助的人很可能会被抛在后面。
将事情带回云计算的具体发展，这也反映了AI Ops的增长——其中机器学习用于分析来自正在运行的应用程序的日志和遥测数据，以确定问题和改进领域。
我不相信我们会很快开发出通用的人工智能 ，因此剧烈的变化可能仅限于各个行业和用例。但这些部门的变化可能仍然是一场彻底的革命。这些变化可能会突然发生，而少数拥有该技术的公司会从中受益，从而进一步加剧社会的经济分裂。
我的恐惧源于知道我什至没有想象过一些可能性，而人工智能的变化几乎可以在一夜之间发生。科幻作家经常谈论“奇点”——广义上说，当人工智能跨越某个点时，变化会加速，人类将无法预测或跟上进步。对此的一些观点可能是夸张的，但我绝对相信人工智能将产生我们没有预见到的重大社会影响。
混血儿的崛起
目前，本地、裸机和混合市场上似乎有很多来自新老玩家的活动。这不是我密切关注的部门，所以这可能再次偏离目标，但无论如何我都会继续胡说八道。
从外面看，一切都不可避免地转向公共云，但我相信我们正处于回归内部部署和混合混合的开始。戴尔和HPE等传统硬件公司在此过程中可能犯了很多错误，但它们似乎都在向*aaS模式迈进，即消费者按使用量付费。起初，这听起来与拥有内部部署硬件不兼容，但据推测，这意味着供应商将运送容量过剩的硬件，并保证在需要时快速交付更多硬件。该模型的一个有趣之处在于它可以平衡承诺、资本支出和运营支出。想要降低每个实例的每月成本？同意 5 年合同和/或预先购买硬件。在确定业务模型时想要更灵活的模型吗？签订 1 年合同，但每个实例的费用更高。
该模型以 HPE 的 GreenLake 和戴尔的 Project Apex 为例。鉴于 IBM 最近的收购以及现有的产品和解决方案，可以合理地猜测它们将在市场上采取类似的举措。Nutanix显然也在这一领域，提供支持云资源和/或本地硬件的软件控制平面。控制平面的重要性再怎么强调也不为过——该模型只有在能够轻松集成混合资源并维护基础设施的情况下才能发挥作用。新人Oxide想必也有一些创新计划在这方面，通过在硬件和各种软件层之间提供更好的集成到虚拟机管理程序。还值得指出的是，这与 Equinix 和 Scaleway 等裸机和数据中心公司目前提供并正在建设的产品相距一百万英里 - 不同之处可能在于我们所说的“内部部署”是什么意思？它是在我自己的数据中心运行的东西，还是我在其他数据中心的硬件？我必须拥有这些硬件，还是可以租用它？
在后台，我们还有一组有趣的云提供商和芯片制造商之间的动态。云供应商希望将芯片商品化，这样它们就可以便宜且快速地每隔几年更换一次。芯片制造商希望确保他们尽可能多地向云提供商销售，同时保持对市场的控制。为了留住具有不同需求的多元化客户群，芯片制造商可能会支持 HPE 和戴尔的举措以及任何促进多样化内部部署和边缘计算平台的举措。相比之下，云提供商已经开始构建自己的定制芯片并进军本地市场。
云提供商还与 Cloudflare 和 Fastly 等 CDN 提供商发生争执。这两家公司都已开始提供无服务器计算服务，这些服务利用其数据中心在尽可能靠近客户的地方运营（一种“边缘”计算形式）。通过更接近最终用户，速度和（似乎）成本方面具有主要优势。他们的一大缺点是他们无法访问 AWS 等提供的大量功能 - 通常您只能获得数据存储和计算服务等等。虽然我预计这些服务会大幅增长，但云提供商正在通过积极扩展到CDN 领域来进行反击。
鉴于潜在的成本节约和“锁定”避免，我们将开始看到一些公司“回到”内部部署/混合。云计算将继续占据主导地位，尤其是在初创企业领域，但成熟的公司将考虑是否能够大幅节省 OPEX。也许更难的问题是谁将成为这场运动的最大赢家——传统硬件供应商、裸机和数据中心供应商、边缘计算供应商、云供应商还是管理平面软件供应商？
量子脚注
量子计算是另一个领域，你可以在大头针上写下我所知道的一切，然后戳我的眼睛。
鉴于量子计算涉及真空和接近绝对零的温度，我们似乎不太可能在短期内获得量子笔记本电脑。事实上，成本如此之高，以至于只有大公司和政府才能负担得起自己的量子计算机。这不切出量子计算然而公众-主要的云提供商都宣布了研究量子和服务的租金。它们为NP Complete问题提供了潜在的重大突破，例如分子模拟和优化逻辑问题。这也可能意味着对于那些负担得起的人来说，TLS 已被破坏. 目前看来，量子计算将为某些类别的问题提供重要的加速，但不会在短期内颠覆计算。真正的影响可能是加速科学领域的研究（想想物理、化学和生物模拟），这反过来可能会导致其他地方的突破。
量子隐形传态似乎更有可能带来对公众至关重要的重大突破——我们能否在地球两端（以及更远的地方！）之间实现比光速更快的高带宽通信？同样，我认为我们离影响 Joe Public 的技术还有一段距离。
转自：https://blog.container-solutions.com/10-predictions-for-the-future-of-computing
本文为转载文章，版权归原作者所有，不代表本站立场和观点。
