天涯论坛

 找回密码
 立即注册
搜索
查看: 76|回复: 6

将来计算的十大趋势预测,你觉得能中几条?

[复制链接]

3061

主题

3万

回帖

9913万

积分

论坛元老

Rank: 8Rank: 8

积分
99139052
发表于 2024-8-4 14:54:41 | 显示全部楼层 |阅读模式

作者 | Adrian Mouat

译者 | 平川策划 | 万佳

本文最初发布于 Container Solutions,经原作者授权由 InfoQ 中文站翻译并分享。

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 似乎是排名第1的语言,由于供给了很好的支持,况且生成的文件相对较小(得益于前面说到 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 就失灵了。日前来看,量子计算能够为某些类型的问题带来重要的速度提高,但在短期内不会颠覆计算。真正的影响可能是加速科学行业理学、化学、生物模拟)的科研而后反过来在其他地区取得突破性发展

量子传送似乎更有可能带来针对公众而言更重要的突破——咱们不可在地球两端(及更远的地区)实现超光速通信?再说一遍,我认为,量子计算要对平民大众产生影响还有很长的路要走。

原文链接:

https://blog.container-solutions.com/10-predictions-for-the-future-of-computing

今日好文举荐阿里腾讯程序员写的代码就比别人好?你不晓得大厂们操碎了多少心实测微X解除外链屏蔽,可打开淘宝链接;iPhone 13预售秒光;JDK/Java 17发布 | Q新闻屏蔽外链最后一天!你的微X能够刷抖音、逛淘宝了吗?作死?放弃保持15年的原生研发,1Password代码所有重写,用户炸了! 活动举荐

程序员工作中还遇到过那些让人哭笑不得想让人吐槽的呢?

点击下方视频号评论留言,咱们选择抽3位点赞最高的粉丝送出精美礼品

点个在看少个 bug 





上一篇:微X大更新,10 年最清爽版本
下一篇:姑婆精英会彦心:我的SEO,SEM以及微X公众号运营经验
回复

使用道具 举报

0

主题

1万

回帖

1

积分

新手上路

Rank: 1

积分
1
发表于 2024-9-8 04:44:55 | 显示全部楼层
你的见解独到,让我受益匪浅,非常感谢。
回复

使用道具 举报

0

主题

1万

回帖

1

积分

新手上路

Rank: 1

积分
1
发表于 2024-9-8 11:58:32 | 显示全部楼层
回顾过去一年,是艰难的一年;展望未来,是辉煌的一年。
回复

使用道具 举报

2986

主题

3万

回帖

9956万

积分

论坛元老

Rank: 8Rank: 8

积分
99569168
发表于 2024-10-5 09:04:13 | 显示全部楼层
你的留言真是温暖如春,让我感受到了无尽的支持与鼓励。
回复

使用道具 举报

3070

主题

3万

回帖

9915万

积分

论坛元老

Rank: 8Rank: 8

积分
99158931
发表于 2024-10-10 22:49:09 | 显示全部楼层
你的留言真是温暖如春,让我感受到了无尽的支持与鼓励。
回复

使用道具 举报

3070

主题

3万

回帖

9915万

积分

论坛元老

Rank: 8Rank: 8

积分
99158931
发表于 2024-10-29 06:48:02 | 显示全部楼层
感谢您的精彩评论,为我带来了新的思考角度。
回复

使用道具 举报

3069

主题

3万

回帖

9913万

积分

论坛元老

Rank: 8Rank: 8

积分
99138952
发表于 2024-11-2 01:00:02 | 显示全部楼层
祝福你、祝你幸福、早日实现等。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

站点统计|Archiver|手机版|小黑屋|天涯论坛 ( 非经营性网站 )|网站地图

GMT+8, 2024-11-23 01:27 , Processed in 0.137218 second(s), 21 queries .

Powered by Discuz! X3.4

Copyright © 2001-2023, Tencent Cloud.