云原生技术快速发展,这里有几个有趣的技术趋势,已经在过去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