轻松入门这款雕刻类App，手把手教你捏只「卡比」
|
今天的云原生技术，起源于 Docker 以及容器这个创新性的技术革命，又受益于经典 PaaS （比如 Cloud Foundry）持续已久的心智普及，最终在开发者与平台构建者的双重关注下，以 Kubernetes 生态为载体最终落地。 在 2020 年，伴随着云原生技术逐步成熟，面向用户的应用管理平台的形态也逐渐开始从以 Cloud Foundry/Heroku 为主体的经典 PaaS 形态（即：企业级 PaaS），向轻量级的 App Service 比如 Shipa 和 Kalm 等方向靠拢。不过，轻量级 App Service 本质上还是 Heroku 体验在 Kubernetes 底座上的复刻，它们在提供出色的开发者使用体验的同时，也继承了经典 PaaS 的“封闭”与“不可扩展”，这在很多大型企业基于云原生技术栈“DIY”属于自己的“PaaS”的诉求下，依然会显得力不从心。 事实上，对于越来越多的平台构建者来说，随着云原生技术的日趋落地，“PaaS”本身的“解释权”不再属于某一家提供商，而更多取决于平台构建者的业务场景和其终端用户的实际需求。此外，对于 “SaaS”来说，云原生带来的容器化软件打包与交付体系和 Kubernetes 底座，也已经极大的改变了云端软件的分发与运维方式。所以，无论是 PaaS 也好，SaaS 也好，本质上正在被“云原生”的技术浪潮迅速“压平”，在这种背景下，传统“水平”划分云计算体系的方法其实已经变得难以自洽。一个典型的例子就是今天你既不能把 Kubernetes 称作是 PaaS，也不能把它称作是 IaaS。它是一个独特的基础设施能力接入层与平台层抽象，作为平台构建者，你可以基于它构建你心目中任何上层平台，而至于你把这个上层平台称作是 PaaS，Serverless，FaaS，甚至是 SaaS，只是进一步抽象的程度和依赖的垂直能力不同而已：这里并没有”谁盖在谁头上”这样的划分。 下一代云原生平台构建体系的崛起 Kubernetes 的成功，极大的使能了“平台构建者”这个以往被人们遗忘在企业成本中心（Cost Center） 里的重要角色。事实上，Kubernetes 之所以能够取代 Docker 生态成为今天云计算平台上的主角，很大程度上是这个群体做出了最终的决定。否则，按照 Docker 所触达到的用户群体规模以及其在开发者生态中的被接纳度， Kubernetes 几乎毫无胜算。这一点经常是被大家所忽视的。实际上，在企业级平台落地的过程中，平台的最终用户（比如业务研发与运维）虽然是“顾客与上帝”，但真正能在这个过程中能起到关键作用和具有最终决定权的，往往还是业务背后的平台团队和老板们。 但与此同时，Kubernetes 之上的平台构建生态，在今天依然是高度集中的。一个典型的观察就是，今天能够基于 Kubernetes 成体系构建出完整上层平台的团队，其实集中在一、二线大型互联网公司当中，并且其实践往往“仅供参考”，鲜有可复制性。进一步的，云原生的极大普及，似乎并没有真正能够让平台构建者轻松的构建 PaaS 或者其他上层平台。这，其实也进一步解释了前面我们观察到的“PaaS 生态“在云原生时代的停滞：基于 Kubernetes 构建上层平台（包括 PaaS），在 2020 年依然是大型公司和高技术水位团队们的专利。 这种平台构建这生态的高度集中，与云原生希望构建的“普惠式”未来，显然是不相符的。当然，既然技术发展还没有跟上愿景，那么云原生社区也就不会停下脚步。 事实上，平台构建者之所以要基于 Kubernetes 进一步构建上层平台，其根本动机无非来自两个诉求：
所以说，基于 Kubernetes 构建上层平台在今天看起来似乎杂乱无章、没什么规律，但本质上都不会离开“抽象 + 插件能力管理”这两个核心诉求。再举个例子，今天大家为 Kubernetes 构建的各种 Dashboard，其实就是一种“抽象”的实现方式：这些 Dashboard 本质上是在 Kubernetes API 对象的基础上暴露出了一组允许用户填写的字段，从而实现了‘’简化用户使用心智、提升用户体验‘’的目的 —— 这当然也是所有“抽象”的根本目标。 基于对“抽象 + 插件能力管理”这两个诉求的持续实践与思考，云原生社区在 2020 年诞生了像 KubeVela 这样专注于使能平台团队构建上层平台的开源项目。这个项目的定位在整个云原生生态中是非常独特的：它并不是某种垂直能力，它更像是一套基于 Kubernetes 构建上层平台的“工具”组合，比如：
（编辑：宜春站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
