Serverless Devs Model 与模型简介

Serverless Devs Model(SDM,下文简称 SDM)的官方文档,主要用于介绍 SDM 的模型详情与相关规范。
Serverless Devs Model(SDM) 是一种与厂商 FaaS 平台无关的 Serverless 架构工具链模型,用于定义通用的 Serverless 架构工具使用标准,让开发者更专注于业务逻辑,提升 Serverless 应用开发、部署、运维效率,通过该模型,开发者可以通过一种更灵活、更通用的方法使用不同云厂商以及开源的 Serverless 产品,进而更高效、更简洁、更便利的实现 Serverless 应用管理。
模型介绍
"Serverless 应用的开发人员应该更关心业务代码,而不需要更多精力去适应不同 Serverless 平台(包括不同厂商的开发者工具学习,不同功能的使用等)。"

就目前来看 Serverless 架构厂商锁定严重,不同厂商会有不同的工具,不同的使用途径,这使得开发者在应用开发的过程中,以及在混合云部署、运维的过程中面临了诸多困难:
学习难度大:开发者要针对不同的云厂商学习不同的工具使用方法,接受不同 Serverless 平台的使用方法,包括不限于发布部署、运维、构建等众多流程;
工具扩展差:很多 Serverless 平台提供的开发者工具,往往是由开发团队提供对应的功能,使用者仅具有使用的功能,如需进行部分的定制化能力,或拓展能力,是难以扩展的;
适配成本高:多云部署,业务迁移是生产过程中常见的行为,由于 Serverless 架构厂商锁定严重导致多云部署、业务迁移时学习成本以及转换成本非常高;
在 Serverless Devs Model(SDM) 中,我们提出了一种以应用为中心,以组件为途径的方法:
应用概念优先:该模型将会以应用纬度进行项目管理,而不再单单以资源形式进行项目管理,这将对应用的开发和定义有着更清晰的定义;
组件化功能透出:该模型将不会提供任何与 Serverless 平台相关的功能,这些所有的功能都将会通过组件,以一种可插拔的形式对开发者透出,Serverless 开发者可以在一个应用中,同时使用多种组件,实现一个完整的应用部署,甚至可以同时实现混合云的部署;
通用功能的抽象:该模型将会推进 Serverless 架构在不同平台下的通用功能的抽象,例如应用的构建、调试功能等都可以通过组件形式进一步抽象为更多的 Serverless 开发者提供开发支持;
:trophy: 我们的目标是:
开发者可以通过一套工具更简单、更方便、更快速的使用不同 Serverless 平台的产品/功能,包括不限于构建、调试、部署、运维等不同的流程或者阶段;
开发者可以以应用的视角去看到 Serverless 应用,甚至是可以通过一行命令将 Serverless 应用部署到不同的 Serverless 平台;
开发者可以非常简单的进行 Onboarding 的流程,可以体验一致的进行不能上层能力的抽象;
Serverless Devs Model(SDM)目前最新版本是 v0.0.1,最新版本文档是由 Serverless Devs 社区发起编写的第一版关于 Serverless 工具链的规范模型文档。该文档将会主要通过 Serverless 工具链体系中的 Registry 模型,开发工具模型以及用户使用模型三个模块进行撰写。

由上图所示,Serverless Devs 的开发角色分为两部分:
Package developer:指的是开发/贡献符合 Serverless Package Model 规范的组件或者公开的应用案例;这部分开发者通常会吧应用发布到对应的 Registry 上;
Serverless developer:指的是 Serverless 应用的开发者,这部分开发者通过使用 Package developer 开发的公共应用案例或者引用不同的组件,将自己的应用部署到不同的 Serverless 平台,或者对应用进行不同的处理,包括不限于构建、观测、压测、调试等;
同时通过上图也可以看到两个比较明显的词汇:Component 和 Application:
Component:指的是组件;是由 Package developer 开发并发布的符合 Serverless Package Model 规范的一段代码,通常这段代码会在应用中被引用,并在 Serverless Devs 开发者工具 中被加载,并按照预定的规则进行执行某些动作。例如,将用户的代码部署到 Serverless 平台;将 Serverless 应用进行构建和打包;对 Serverless 应用进行调试等;
Application:指的是应用;可以由 Package developer 公开发布到 Registry,以供更多人学习和使用,例如某位贡献者贡献了一个猫狗识别的案例到 Registry;也可以由 Serverless developer 开发,例如某人开发了一个 人脸识别的应用;通常情况下一个应用可以引用一个或者多个组件,并通过 Serverless Devs 开发者工具 工具部署到 Serverless 平台,例如我开发了一个猫狗识别的应用,在这个应用中引用了 Lambda 组件帮助我将部分业务逻辑部署到 FaaS 平台,同时我也引用了 Website 组件帮助我把前端业务代码部署到对象存储中;
通过上图,同样也可以看到 Serverless Devs Model 包含了以下三个模块:
Registry 模型:一个开放的 Serverless Registry Model。Package 的开发者可以将自己开发的组件,或者待分享的应用发布到该平台。该平台可以使用目前 Serverless Devs 所支持的 Github Resitry, Gitee Registry, Serverless Registry,也可以按照该规范搭建私有的 Registry 以完成部分能力。
开发包模型:一个关于 Serverless Package 的规范。Package developer 需要遵循该规范进行组件的开发或者应用的共享,否则将无法被 Serverless Devs 开发者工具 工具所识别和加载,也无法被 Application 所引用,并实现预期的功能。
用户使用模型:Serverless developer 在进行应用开发时所需要遵守的约定,以确保 Serverless Devs 开发者工具 可以准确识别相对应的内容,并按照预期加载对应的 Component,完成预期的功能。
版权声明: 本文为 InfoQ 作者【刘宇】的原创文章。
原文链接:【http://xie.infoq.cn/article/5a392fa2d7a43bfcce7e3d3e8】。文章转载请联系作者。
评论