原文地址：https://www.aniszczyk.org/2021/01/19/cloud-native-predictions-for-2021-and-beyond/
本文内容翻译自Chris Aniszczyk的个人博客
我希望每个人都能度过一个美好的假期，因为2021年1月的头几个星期，从暴动到新的COVID毒株都相当疯狂。 在云原生领域，CNCF最近发布了有关我们去年完成的所有工作的年度报告。 我建议大家趁此机会阅读这份报告，鉴于大流行情况，我们度过了坚实的一年。
https：//twitter.com/CloudNativeFdn/status/1343914259177222145
作为我工作的一部分，我在为与我合作的所有成员公司和开发人员提供云原生趋势方面，有一定的优势，因此我想我对2021年及以后的发展方向有自己的看法：
图片
云原生IDE（集成开发环境）
作为一个在Eclipse Foundation内部从事研发开发工具的人，我对最新的技术进步感到非常兴奋。未来，开发生命周期（代码，构建，调试）将主要在云中进行，而不是本地Emacs或VSCode设置。您最终将为每个pull请求获得完整的开发环境设置，并对其进行预先配置并连接到其自己的部署中，以帮助您进行开发和调试。今天，通过GitHub Codespaces和GitPod启用了此技术的具体示例。尽管GitHub Codespaces仍处于测试阶段，但您可以现在仍然可以以Prometheus为例使用GitPod来体验。一分钟左右，您便拥有了一个带有编辑器和预览环境的完全实时的开发环境。更妙的是，此开发环境（工作区）是用代码描述的，并且可以像其他任何代码工件一样与团队中的其他开发人员共享。
最后，我希望在明年看到云原生IDE领域的惊人创新，尤其是随着GitHub Codespaces进入beta版并变得更加广泛可用，以便开发人员可以体验这个新概念并爱上它。
Kubernetes 在边缘计算中的应用
Kubernetes是通过在大型数据中心中使用而诞生的，但是Kubernetes会像Linux在新环境中所做的那样发展。Linux发生的事情是，终端用户最终扩展了内核，以支持移动，嵌入式等更多新的部署方案。我坚信Kubernetes将经历类似的发展，我们已经目睹Telcos（和初创公司）通过将VNF转换为Cloud Native Network Functions（CNF）以及k3s，KubeEdge，k0s，LFEdge，Eclipse ioFog等开源项目来探索Kubernetes作为边缘平台的应用。推动超大规模云支持电信运营商和边缘计算的力量，再加上基于已经存在的大型生态系统重用云原生软件的能力，将使Kubernetes在未来几年内成为边缘计算的主导平台。
云原生+Wasm
Web Assembly（Wasm）是一项新兴技术，但我希望它成为云原生生态系统中日益增长的实用程序和工作负载，尤其是随着WASI的成熟以及Kubernetes如前所述被更多用作边缘协调器。 一种用例是为扩展机制提供动力，例如Envoy对过滤器和LuaJIT所做的工作。 您可以使用支持各种编程语言的更小的优化runtime，而不必直接与Lua进行交易。 Envoy项目目前正在采用Wasm，在任何环境下，脚本语言都是一种流行的扩展机制，将来都会被Wasm取代，我希望在任何环境下都可以采用类似的模式。
在Kubernetes方面，有像Microsoft的Krustlet这样的项目正在探索如何在Kubernetes中支持基于WASI的runtime。这并不奇怪，因为Kubernetes已经通过CRD和其他机制进行了扩展，以运行不同类型的工作负载，例如VM（KubeVirt）等。
另外，如果您是Wasm的新手，我建议您从Linux Foundation及其出色的文档那里学习这个新的入门课程。
FinOps的崛起 (CFM)
冠状病毒的爆发加速了向云原生的转变。在危机中，至少有一半的公司正在加速其云计划……近60％的受访者表示，由于COVID-19大流行（2020年云状态报告），云的使用将超过先前的计划。最重要的是，云财务管理（或FinOps）是许多公司日益关注的问题，在过去的六个月中，约有一半的讨论涉及到公司在云原生领域的发展，这是老实讲的问题。您还可以辩称，云提供商并未受到激励，无法使云财务管理变得容易，因为这将使客户更容易减少支出，但是，我的真正痛苦在于缺乏围绕云财务管理的开源创新和标准化（所有的云都以不同的方式进行成本管理）。在CNCF环境中，没有多少开源项目试图简化FinOps，有KubeCost项目，但还处于初期。
另外，Linux基金会最近启动了“ FinOps基金会”以帮助该领域的创新，他们在该领域提供了一些很棒的入门资料。 我希望在未来几年中在FinOps领域看到更多的开源项目和规范。
云原生中更多使用Rust
Rust仍然是一门新兴而小众的编程语言，特别是如果以Redmonk的编程语言排名为例。但是，我的感觉是，鉴于已经有少数CNCF项目利用Rust在诸如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时代成长的一些人来说，您可能还记得CMDB（恐怖）之类的东西。但是，随着微服务和云原生开发的兴起，对服务进行分类并为各种实时服务元数据建立索引的能力对于推动开发人员自动化至关重要。这可以包括使用服务目录来了解所有权以处理事件管理，管理SLO等。
将来，您将看到开发人员仪表板的趋势，该仪表板不仅是服务目录，而且还具有通过各种自动化功能将仪表板扩展到一个地方的能力。 典范的开源示例是Lyft的Backstage和Clutch，但是，任何具有相当现代的云原生部署的公司都倾向于拥有一个平台基础架构团队，他们试图构建类似的东西。 随着开放源代码开发人员仪表板和大型插件生态系统的成熟，您会发现各地的平台工程团队都在加快采用速度。
跨云变得更加真实
Kubernetes和云原生动态表明，在生产环境中可以使用云原生方法和多云方法，数据清楚地表明：“ 93％的企业制定了使用Microsoft Azure，Amazon Web Services和Google Cloud等多个提供商的策略”（2020年云状态报告）。Kubernetes已随着云市场的发展而成熟，这一事实有望解锁程序化跨云托管服务。这种方法的具体示例体现在Crossplane项目中，该项目提供了一个开源的跨云控制平面，该平台利用Kubernetes API的可扩展性来实现跨云工作负载管理（请参阅“ GitLab部署跨平面控制平面以提供多云部署”）。
主流eBPF
eBPF允许您在Linux内核中运行程序而无需更改内核代码或加载模块，您可以将其视为沙盒扩展机制。 eBPF允许新一代软件扩展Linux内核的行为，以支持各种不同的事物，包括改进的网络，监控和安全性。 从历史上看，eBPF的缺点是需要使用现代内核版本才能利用它，而且很长一段时间以来，对于许多公司来说，这都不是一个现实的选择。 但是，情况正在发生变化，即使是较新版本的RHEL最终也支持eBPF，因此您将看到更多的项目可以利用。 如果您查看Sysdig的最新容器报告，您会发现Falco的采用率最近有所上升，尽管该报告可能与Sysdig有所偏差，但它反映在生产使用情况中。 因此，请继续关注并在将来寻找更多基于eBPF的项目！
最终，祝2021快乐！
我还有其他一些预测和趋势可以分享，尤其是在最终用户驱动的开源，服务网格同类化/标准化，Prometheus + OTel，用于保护软件供应链的KYC等方面，还有更多，但我会保留下来，以保留更详细的帖子，九个预测 足以开始新的一年！ 无论如何，感谢您的阅读，我希望2021年5月在KubeCon + CloudNativeCon EU上看到大家，报名已经开始！
公众号搜索“拓扑软件”，查看更多~