【译】2021 年及未来的云原生预测
本文译自 Cloud Native Predictions for 2021 and Beyond
原文发布在 Chris Aniszczyk 的个人博客
我希望每个人都有一个美好的假期，因为 2021 年 1 月的前几周一直非常疯狂，从叛乱到新的 COVID 菌株。在云原生国度，CNCF 最近发布了关于我们去年完成的所有工作的年度报告。我建议大家找个机会去看一下这份报告，在疫情大流行的这一年，我们收获颇丰。https://twitter.com/CloudNativeFdn/status/1343914259177222145
作为我工作的一部分，我对云原生趋势有一个独特的观点，送给所有与我合作的会员公司和开发人员，所以我想我会分享我对 2021 年及以后云原生发展的想法。
云原生的 IDE
作为一个在 Eclipse 基金会内部从事开发者工具工作的人，我对最近的技术状态进展感到无比兴奋。未来，开发生命周期（代码、构建、调试）将主要发生在云端，而不是你本地的 Emacs 或 VSCode。你将每一个拉动请求最终得到一个完整的开发环境设置，预先配置并连接到他们自己的部署，以协助你的开发和调试需求。今天这种技术的一个具体例子是通过 GitHub Codespaces 和 GitPod 实现的。虽然 GitHub Codespaces 还处于测试阶段，但今天你可以通过 GitPod 来体验，以 Prometheus 为例。一分钟左右，你就拥有了一个有编辑器和预览环境的完全实时的开发环境。最疯狂的是，这个开发环境（工作空间）是 用代码描述，并且可以像其他代码工件一样，与你团队的其他开发者共享。
最后，我期望在接下来的一年里，能看到云原生 IDE 领域出现令人难以置信的创新，特别是随着 GitHub Codespaces 进入测试版之后，并得到广泛地使用，让开发者可以体验到这个新概念，并爱上它。
边缘的 Kubernetes
Kubernetes 是通过在大规模数据中心的使用而诞生的，但 Kubernetes 会像 Linux 一样为新的环境而进化。Linux 所发生的事情是，终端用户最终对内核进行了扩展，以支持从移动、嵌入式等各种新的部署场景。我坚信 Kubernetes 也会经历类似的进化，我们已经见证了 Telcos（和其他初创公司）通过将 VNFs 转化为 云原生网络功能（CNFs），以及 k3s、KubeEdge、k0s、LFEdge、Eclipse ioFog 等开源项目，来探索 Kubernetes 作为边缘平台。推动超大规模云服务支持电信公司和边缘的能力，再加上重用云原生软件的能力，以及建立在现有庞大的生态系统基础上的能力，将巩固 Kubernetes 在未来几年内成为边缘计算的主导平台。
云原生 + Wasm
Web Assembly(Wasm) 是一项新的技术，但我预计它将成为云原生生态系统中不断增长的实用工具和工作负载，特别是随着 WASI 的成熟，以及 Kubernetes 更多地作为边缘编排工具使用，如前所述。一个场景是增强扩展机制，就像 Envoy 对过滤器和 LuaJIT 所做的那样。你可以与一个支持各种编程语言的更小的优化运行时协同，而不是直接与 Lua 打交道。Envoy 项目目前正处于 采用 Wasm 的过程中，我预计任何使用脚本语言作为流行扩展机制的环境都会出现被 Wasm 全盘取代的情况。
在 Kubernetes 方面，有像微软的 Krustlet 这样的项目，正在探索如何在 Kubernetes 中支持基于 WASI 的运行时。这不应该太令人惊讶，因为 Kubernetes 已经在通过 CRD 和其他机制扩展，以运行不同类型的工作负载，如 VM（KubeVirt）等等。
另外，如果你是 Wasm 的新手，我推荐 Linux 基金会的这本新的 入门课程，它对其进行了介绍，以及优选的文档。
FinOps 的崛起（CFM）
新冠病毒的爆发加速了向云原生的转变。至少有一半的公司在危机中加快了他们的云计划。近 60% 的受访者表示，由于 COVID-19 大流行，云计算的使用量将超过之前的计划 (2020 年云计算现状报告)。除此之外，云财务管理 (或 FinOps) 对许多公司来说是一个日益严重的问题和 关注，老实说，在过去 6 个月里，我与正在进行云原生之旅的公司进行的讨论中，大约有一半的讨论都会提到这个问题。你也可以说，云提供商没有动力让云财务管理变得更容易，因为这将使客户更容易减少支出，然而，在我看来，真正的痛苦是缺乏围绕云财务管理的开源创新和标准化（所有的云都以不同的方式进行成本管理）。在 CNCF 的背景下，试图让 FinOps 变得更容易的开源项目并不多，有 KubeCost 项目，但还相当早期。
另外，Linux 基金会最近推出了 FinOps 基金会 来帮助这个领域的创新，他们在这个领域有一些 很棒的入门材料。我期望在未来几年，在 FinOps 领域能看到更多的开源项目和规范。
云原生中更多的使用 Rust
Rust 仍然是一门年轻而小众的编程语言，特别是如果你以 Redmonk 的 编程语言排名 为例。然而，我的感觉是，鉴于已经有一些 使用 Rust 的 CNCF 项目，以及它出现在像 microvm Firecracker 这样有趣的基础设施项目中，你将在未来一年中看到 Rust 出现在更多的云原生项目中。虽然 CNCF 目前有超多的项目是用 Golang 编写的，但我预计随着 Rust 社区的成熟，几年后基于 Rust 的项目将与基于 Go 的项目平起平坐。
GitOps+CD/PD 增长显著
GitOps 是云原生技术的一种操作模式，提供了一套统一部署、管理和监控应用程序的最佳实践 (最初是由 Weaveworks 名气很大的 Alexis Richardson创造)。GitOps 最重要的方面是通过声明的方式描述所需的在 Git 中版本化的系统状态，这基本上可以使一系列复杂的系统变更被正确地应用，然后进行验证（通过 Git 和其他工具启用的漂亮的审计日志）。从实用的角度来看，GitOps 改善了开发者的体验，随着 Argo、GitLab、Flux 等项目的发展，我预计今年 GitOps 工具会更多地冲击企业。如果你看过 GitLab 的 数据，GitOps 还是一个大部分公司还没有探索出来的新兴的实践，但随着越来越多的公司大规模采用云原生软件，我认为 GitOps 自然会随之而来。如果你有兴趣了解更多关于这个领域的信息，我推荐你去看看 CNCF 中 新 成立的 GitOps 工作组。
服务目录2.0：云原生开发者仪表盘
服务目录的概念并不是一个新事物，对于我们一些在 ITIL 时代成长起来的老人们来说，你可能还记得 CMDBs （恐怖）等东西。然而，随着微服务和云原生开发的兴起，对服务进行编目和索引各种实时服务元数据的能力对于推动开发者自动化是至关重要的。这可以包括使用服务目录来了解所有权来处理事件管理、管理 SLO 等。
在未来，你将看到开发人员仪表盘的趋势，它不仅是一个服务目录，而且提供了通过各种自动化功能在扩展仪表盘的能力。这方面的典范开源例子是 Lyft 的 Backstage 和 Clutch，然而，任何拥有相当现代的云原生部署的公司往往都有一个平台基础设施团队，他们已经尝试构建类似的东西。随着开源开发者仪表盘与 大型插件生态系统 的成熟，你会看到其被各地的平台工程团队加速采用。
跨云变得更真实
Kubernetes 和云原生运动已经证明了云原生和多云方式在生产环境中是可行的，数据很清楚地表明“93% 的企业都有使用微软 Azure、亚马逊网络服务和谷歌云等多个提供商的策略” (2020 年云计算现状报告)。事实上，Kubernetes 这些年伴随着云市场的发展而更加成熟，将有望解锁程序化的跨云管理服务。这种方法的一个具体例子体现在 Crossplane 项目中，该项目提供了一个开源的跨云控制平面，利用 Kubernetes API 的可扩展性来实现跨云工作负载管理（参见 “GitLab 部署 Crossplane 控制平面，提供多云部署 “）。
主流 eBPF
eBPF 允许你在不改变内核代码或加载模块的情况下，在 Linux 内核中运行程序，你可以把它看作是一种沙箱扩展机制。eBPF 允许 新一代软件 从改进的网络、监控和安全等各种不同的方向扩展 Linux 内核的行为。从历史上看，eBPF 的缺点是它需要一个现代的内核版本来利用它，在很长一段时间里，这对许多公司来说都不是一个现实的选择。然而，事情正在发生变化，甚至新版本的 RHEL 终于支持 eBPF，所以你会看到更多的项目利用其 [优势]（https://sysdig.com/blog/sysdig-and-falco-now-powered-by-ebpf/）。如果你看过 Sysdig 最新的 容器报告，你会发现 Falco 的采用率最近在上升，虽然 Sysdig 的报告可能有点偏颇，但它反映在生产使用上。所以请继续关注，并期待未来更多基于 eBPF 的项目。
最后，祝大家 2021 年快乐！
我还有一些预测和趋势要分享，尤其是围绕终端用户驱动的开源、服务网格拆解/标准化、Prometheus+OTel、保障软件供应链安全的 KYC 等等，但我会把这些留到更详细的文章中去，9 个预测足以开启新的一年！总之，感谢大家的阅读，希望在 2021 年 5 月的 KubeCon+CloudNativeCon EU 上与大家见面，报名已开始！
