下一代云原生平台构建体系的崛起
-
Kubernetes 的成功,极大使能了“平台构建者”这个以往被人们遗忘在企业成本中心(Cost Center) 里的重要角色。事实上,Kubernetes 之所以能够取代 Docker 生态成为今天云计算平台上的主角,很大程度上是这个群体做出了最终的决定。否则,按照 Docker 所触达到的用户群体规模以及其在开发者生态中的被接纳度, Kubernetes 几乎毫无胜算。这一点经常是被大家所忽视的。实际上,在企业级平台落地的过程中,平台的最终用户(比如业务研发与运维)虽然是“顾客与上帝”,但真正能在这个过程中起到关键作用和具有最终决定权的,往往还是业务背后的平台团队和老板们。 但与此同时,Kubernetes 之上的平台构建生态,在今天依然是高度集中的。一个典型的观察就是,今天能够基于 Kubernetes 成体系构建出完整上层平台的团队,其实集中在一、二线大型互联网公司当中,并且其实践往往“仅供参考”,鲜有可复制性。进一步的,云原生的极大普及,似乎并没有真正能够让平台构建者轻松地构建 PaaS 或者其他上层平台。这其实也进一步解释了前面我们观察到的“PaaS 生态“在云原生时代的停滞:基于 Kubernetes 构建上层平台(包括 PaaS),在 2020 年依然是大型公司和高技术水位团队们的专利。 这种平台构建生态的高度集中,与云原生希望构建的“普惠式”未来,显然是不相符的。当然,既然技术发展还没有跟上愿景,那么云原生社区也就不会停下脚步。 事实上,平台构建者之所以要基于 Kubernetes 进一步构建上层平台,其根本动机无非来自两个诉求:更高的抽象维度:比如,用户希望操作的概念是“应用”和“灰度发布”,而不是“容器”和“Pod”。更多的扩展能力:比如,用户希望的应用灰度发布策略是基于“双 Deployment + Istio” 的金丝雀发布,而不是 Kubernetes 默认的 Pod 线性滚动升级。这些增强或者扩展能力,在 Kubernetes 中一般是以 CRD + Controller 的插件方式来实现的。 所以说,基于 Kubernetes 构建上层平台在今天看起来似乎杂乱无章、没什么规律,但本质上都不会离开“抽象 + 插件能力管理”这两个核心诉求。再举个例子,今天大家为 Kubernetes 构建的各种 Dashboard,其实就是一种“抽象”的实现方式:这些 Dashboard 本质上是在 Kubernetes API 对象的基础上暴露出了一组允许用户填写的字段,从而实现了“简化用户使用心智、提升用户体验”的目的 —— 这当然也是所有“抽象”的根本目标。 基于对“抽象 + 插件能力管理”这两个诉求的持续实践与思考,云原生社区在 2020 年诞生了像 KubeVela 这样专注于使能平台团队构建上层平台的开源项目。这个项目的定位在整个云原生生态中是非常独特的:它并不是某种垂直能力,更像是一套基于 Kubernetes 构建上层平台的“工具”组合。 可以预见,在云原生与 Kubernetes 项目极大程度地统一与标准化了基础设施层抽象之后,如何进一步帮助平台团队在此之上快速、轻松、可复制地构建上层平台,正在成为业界开始积极思考的一条关键路径。再一次的,你很难在传统的云计算“三层架构”中找到适合这些产品的位置,无论是 KubeVela 还是 AWS Proton,它们既不是 PaaS,也不是 IaaS,更不是 Kubernetes 的竞争者:它们是云原生背景下新一代平台构建体系逐步崛起的萌芽。
西南地区IT社群(QQ)
- 云南
- 【昆明网页设计交流吧】243627302
- 【昆明nodejs交流吧】 243626749
- 【VUE】838405306
- 【云南程序员总群】343606807
- 【昆明UI设计】104031254
- 【云南软件外包】15547313
- 贵州
- 【PHP/java源码/站长交流群】55692114
- 四川
- 【成都Java/JavaWeb交流】86669225
- 【vaScript+PHP+MySql】116270060
- 【UI设计/设计交流学习群】135794928
- 重庆
- 【诺基亚 JAVA游戏博物馆】 559479780
- 【PHP,Java,Python,C++接单】 442103442
- 西藏