云原生技术快速发展，这里有几个有趣的技术趋势，已经在过去12个月出现，而且将在未来几年深刻影响云原生。
系统设计：单体归来
在过去的几年里，用微服务构建云原生应用程序兴起，它将一个大型应用程序分解成更小的、相互连接的组件，允许独立的团队处理应用程序的不同部分而不必互相干涉。然而，微服务也面临着一系列挑战，最大的挑战是跨组件调试的困难。Kubernetes的传道者Kelsey Hightower提出了一个想法，“单体是未来，因为人们试图用微服务解决的问题并不符合现实。”实际上，核心云原生应用程序Istio服务网格背后的设计团队，正在迁移到单体的方法，其中更多的服务被集成到一个单一的守护进程中。
折中无处不在，2020年，微服务与企业软件设计中的其他因素开始平衡。
云服务：一个统一的控制平面
Kubernetes在如何方便地扩展和管理分布式应用程序方面带来了一场革命，尽管它的接口主要面向系统管理员。对于开发人员来说，它意味着一个陡峭的学习曲线，需要在它自己的运维概念（即“入口”、“pods”、“服务”）和开发人员所理解的应用程序的实际需求之间进行大量的转换。因此，毫不奇怪，今年我们看到了很多关于一个通用的控制平面的讨论，它将为企业为其开发人员构建自己的基于Kubernetes的自助式平台（即服务）奠定基础。Kubernetes就在下面，开发者不必担心。关键的早期工作是一个称为Open Application Model（OAM）的标准化模板，它正在迅速成为Kubernetes社区中的事实标准。Crossplane是Upbound构建的一个基于OAM的开源控制平面，在这个领域获得了很多关注。IBM现在正在测试Crossplane，以帮助用户在其IBM Cloud上统一操作。另一个获得关注的基于OAM的项目是KubeVela，它是一个可扩展的“平台引擎”。
“对于开发人员来说，KubeVela是一个易于使用的工具，它使你能够以最小的努力来描述应用程序并将其发送给Kubernetes，而对于平台构建者来说，KubeVela是一个框架，使他们能够轻松地创建面向开发人员但完全可扩展的平台。”
运维：可编程Linux内核
Linux内核是云原生的事实标准操作系统，由于Extended Berkeley Packet Filter（eBPF）的引入，它的使用方式开始发生根本性的转变。虽然最初的目标是用于高级内核监控，但这个原始BPF的内存映射扩展可以在内核空间中运行任何沙盒程序，而无需更改内核源代码或加载模块。
实际上，eBPF充当了一个微内核，提供了一种可能更快、更安全的方式来使用Linux内核。通过这种方式，eBPF为开发人员提供了一种将自己的程序添加到内核本身的方法。最直接的好处将是应用程序和系统监控（和调试），以及加快网络路由的决策过程，允许内核内联完成迄今为止交给模块的工作。目前，几家专注于Kubernetes的公司，如Cilium、Isovalent和Tigera，正在使用这项技术为使用Kube-Proxy进行流量路由提供一种更快的替代方案。
安全：重新思考漏洞管理
在过去的一年里，越来越明显的是，当前用于处理新安全漏洞的系统可能没跟上云原生计算的步伐。来自云安全公司Rezilion的Tal Klein指出，目前全行业范围内对新发现的漏洞进行优先排序的系统，即通用漏洞评分系统（CVSS），与攻击者如何利用漏洞来破坏系统的方式不符。有些人认为，人们过于关注严重程度评分本身，对评分所涉及的环境背景了解不够。Rezilion发现67%~75%具有“高严重性”CVSS分数的漏洞从未加载到内存中，因此不可能被利用。同时，鉴于实际修补评级较低漏洞的公司越来越少，攻击者转而利用评级较低的漏洞。
开发：慢慢远离C++
几十年来，我们的操作系统和其他重要基础设施软件都是用C语言或C++语言编写，它们是快速、低级语言。然而，现在越来越多的系统架构师得出这样的结论：完全保护用这些语言编写的程序是非常困难的，因为它们处理内存和其他因素的不安全方式。要安全地处理内存分配需要大量的人才，即便如此，一个被忽视的错误也可能会导致错误。最近，更多的拥护者们开始使用一种新的语言——RIST，它既有C/C++的速度，也有编写安全应用所必需的安全性。在今年早些时候的AllThingsOpen虚拟会议期间，微软云开发者倡导者Ryan Levick解释了为什么微软逐渐转向RID来构建其基础设施软件，也鼓励其他软件业巨头考虑同样的问题。
原文链接：The New Stack:Top Cloud Native Technology Trends from 2020–The New Stack
