2021年云原生趋势预测

我希望每个人都度过了一个美好的假期，因为2021年1月的头几周非常疯狂，从叛乱到新冠病毒。在云原生(Cloud Native)领域，CNCF最近发布了年度报告，包含我们去年完成的所有工作。我建议每个人有机会都看一看这份报告，考虑到病毒大流行的情况，我们度过了颇有收获的一年。

[[379818]]

云原生作为我工作的一部分，相比我共事过的公司和开发人员，我有独特的优势，所以我想分享一下我对2021年及以后的云原生发展趋势的看法

云原生IDE

作为一个在Eclipse Foundation中花了相当一部分时间在开发人员工具上的人，我对最新的技术进展感到非常兴奋。未来的开发生命周期(代码、构建、调试)将主要发生在云上，而不是你本地的Emacs或VSCode设置中。最终，你将为每个pull请求获得一个完整的开发环境设置，预先配置并连接到它们自己的部署，以帮助你开发和调试需求。这个技术的一个具体例子是通过GitHub Codespaces和GitPod实现的。虽然GitHub的Codespaces还在测试阶段，但是你可以用GitPod来体验一下，比如Prometheus。在一分钟左右的时间内，你就拥有了一个具有编辑器和预览环境的完全实时开发环境。这个开发环境(工作区)是用代码描述的，并且可以像其他代码工件一样与团队中的其他开发人员共享。

最后，我希望在明年看到云原生IDE领域惊人的创新，特别是随着GitHub Codespaces进入测试阶段，并变得更广泛可用，这样开发者就可以体验这个新概念并爱上它。

边缘侧Kubernetes

Kubernetes是通过大规模数据中心的使用而诞生的，但Kubernetes将会像Linux在新环境中所做的那样不断发展。Linux的情况是，最终用户扩展了内核，以支持各种新的部署场景，包括移动部署、嵌入式部署等等。我坚信Kubernetes将经历类似的演变，我们已经看到电信公司(和初创公司)通过将VNFs转换为云原生网络功能(CNFs)，以及k3s、KubeEdge、k0s、LFEdge、Eclipse ioFog等开源项目，将Kubernetes作为边缘平台进行探索。推动超规模云支持电信公司和edge的力量，加上重用云本地软件的能力，以及在已经庞大的生态系统上构建的能力，将在未来几年巩固Kubernetes在边缘计算领域的主导平台地位。

云原生 + Wasm

Web Assembly(Wasm)是一项刚刚起步的技术，但我预计它将成为本地云生态系统中日益增长的实用程序和工作负载，特别是随着WASI的成熟以及Kubernetes更多地用作前面所述的边缘协调器。一个用例是支持扩展机制，就像Envoy使用过滤器和LuaJIT所做的那样。与直接处理Lua不同，你可以使用支持多种编程语言的更小的优化运行时。Envoy项目目前正处于采用Wasm的过程中，我希望在任何环境中都能遵循类似的模式，即脚本语言是一种流行的扩展机制，将来会被Wasm全盘取代。

在Kubernetes的前沿，有一些项目，比如来自微软的Krustlet，正在探索如何在Kubernetes中支持基于wasi的运行时。这并不奇怪，因为Kubernetes已经通过CRDs和其他机制进行了扩展，以运行不同类型的工作负载，如VM (KubeVirt)等。

另外，如果你是Wasm的新手，我推荐这门来自Linux Foundation的新入门课程以及excellection文档。

FinOps崛起(CFM)

冠状病毒的爆发加速了云本地的转变。在危机期间，至少有一半的公司正在加快其云计算计划……近60%的受访者表示，由于COVID-19大流行，云计算使用量将超过之前的计划(2020年云计算状况报告)。除此之外，云财务管理(或称FinOps)是许多公司日益关注的问题，在我过去6个月与正在进行云原生旅程的公司的讨论中，有一半都提到了这个问题。你也可以认为云提供商不鼓励简化云财务管理，因为这样客户将会花费更少，然而，在我看来，围绕云财务管理，真正的痛苦是缺乏开源创新和标准化(每家公司做的云成本管理都不同)。在CNCF环境中，没有多少开源项目试图使FinOps变得更容易，有个KubeCost项目，但它还处于相当早期的阶段。

另外，Linux基金会最近启动了“FinOps基金会”来帮助这个领域的创新，他们在这个领域有一些很好的介绍性材料。我希望在未来几年里在FinOps领域看到更多的开源项目和规范。

更多的Rust出现在云原生

Rust仍然是一门年轻的编程语言，特别是当你以Redmonk的编程语言排名为例时。然而，我的感觉是，在接下来的一年里，你会在更多的云原生项目中看到Rust，因为已经有一些利用Rust的CNCF项目出现在有趣的基础设施项目中，比如microvm Firecracker。虽然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时代长大的老年人来说，可能还记得CMDB(恐怖)之类的东西。然而，随着微服务和云原生开发的兴起，记录服务和索引各种实时服务元数据的能力对于推动开发人员自动化至关重要。这可以包括使用服务目录来了解所有权，以处理事件管理、管理SLO等。

在未来，你将看到开发人员仪表盘的趋势，它不仅是一个服务目录，还提供了通过各种自动化特性在一个地方扩展仪表盘的能力。最典型的开源例子是来自Lyft的Backstage和Clutch，然而，任何拥有相当现代的本地云部署的公司都倾向于拥有一个平台基础架构团队，试图构建类似的东西。伴随着一个大型插件生态系统，开源开发人员仪表盘将更成熟，你将看到各地的平台工程团队加速采用仪表盘。

交叉云变得更加现实

Kubernetes和云本地运动已经证明了云本地和多云方法在生产环境中是可能的，数据清楚地表明“93%的企业有一个战略，使用多个供应商，如微软Azure、亚马逊Web服务和谷歌云”(2020年云报告状态)。Kubernetes多年来随着云市场的成熟，有望开启可编程的跨云管理服务。这种方法的一个具体例子体现在Crossplane项目中，该项目提供了一个开源的跨云控制平面，利用Kubernetes API的可扩展性来支持跨云工作负载管理(参见《GitLab部署跨云控制平面来提供多云部署》)。

主流eBPF

eBPF允许你在Linux内核中运行程序，而无需更改内核代码或加载模块，你可以将其视为一种沙箱扩展机制。eBPF允许新一代软件扩展Linux内核的行为，以支持改进的网络、监控和安全等各种不同的东西。从历史上看，eBPF的缺点是它需要一个现代的内核版本来利用它，在很长一段时间里，这对许多公司来说都不是一个现实的选择。然而，情况正在发生变化，甚至RHEL的新版本最终也支持eBPF，因此你将看到更多的项目从中受益。如果你看一下Sysdig最新的容器报告，你会发现Falco的使用率最近有所上升，尽管该报告可能有点偏向Sysdig，但它反映在生产使用中。所以请继续关注并期待未来更多基于eBPF的项目!