随着kubernetes的兴起，很多公司都有了Paas平台建设的能力，但是应用Paas平台建设上基本上都是形态各异，百花齐放，而OAM在笔者看来就是应用Paas平台建设的kubernetes，未来的事实标准，今天让我们一起来聊下OAM吧。
1. 第1001个Paas平台
在聊OAM之前我们先聊下传统的运维开发，从运维系统到运维平台的演进的过程，以及可能会遇到的问题
1.1 起步阶段
在传统的运维开发中，基础组件CMDB、自动化、监控、发布、日志、流程几个系统基本上已经是标配，通过CMDB存储元数据，自动化提供原子操作，然后通过发布搞定持续交付, 通常可以将这个阶段称为1.0阶段，该阶段运维可以提供一定的支持能力，该阶段运维主要目标是搞定内部需求，对外输出持续交付能力(仅仅是交付，大多数公司CI流程由测试把控，夸团队的事情就自行体会吧)
1.2 平台化阶段
平台化阶段主要目标就是通过运维系统的集成，尽可能的实现研发的自助操作，比较典型的就是基于ITSM实现上述流程平台的联动，研发填写固定的工单，然后通过流程编排，整合当前的运维子系统，实现某个场景的自助化操作，减少运维的参与度，提供研发效能，在这个过程中，可能会打通公司的一些别的团队，比如数据库、测试、中间件团队，姑且称之为2.0阶段
1.3 服务化阶段
服务化Paas主要是通过底层基础设施、运维系统的服务化能力，并且公司内部具有高度统一的目标，开始向云化转变阶段转变，每个团队都提供高度内聚的服务化能力，同时对外提供该平台全生命周期的管理能力。
这里我们要想明白服务化能力与系统功能的区别，比如说发布系统提供几十个参数，让用户提供随意的定义，我理解这可能仅仅是功能，因为如果用户自由度越高，证明平台流程规范越不统一， 而且如果让一个用户用系统的时候，得先屡清楚你的几十个功能参数，上帝，祝你好运！而服务化的能力我理解上应该给用户提供的是比如发布策略，尽可能少的控制参数，标准化的流程，具体的复杂编排能力完全内聚到平台内部，对用户无感知。就称之为3.0阶段好了
1.4 1001种选择
在这个阶段通常平台的建设者就会考虑平台下一步大的方向是什么，从当前的运维产品类中，我们可以分为三个方向：效能devops方向、Paas方向、运维门户，但大家有一个很一致的目标就是提高研发效能，实现应用全生命周期管理
1.4.1 运维门户
运维门户方向其目标主要是覆盖测试->发布->运维这三个阶段,通过整合运维侧的能力，比如cmdb、监控、发布、日志等系统实现应用的统一操作，通常会结合公司的CMDB来实现业务树来进行统一管理，其优点是符合运维操作需求，个人理解其相对于devops和cloud属于建设过程中的一个阶段，主要强调的是整合。
1.4.2 devops效能
效能devops方向典型的代表就是阿里的云效，从需求->开发->测试->发布->运维->运营实现全链路的覆盖，在大多数工通常都是打通测试->发布->运维->运营这个链路就很不错了，但是通常公司大概率不会做这个事情，只要稍微碰过的就知道这里面需求->开发->测试这几个阶段是多难打通了。
1.4.3 Paas
Paas方向除了测试->发布->运维->运营这个链路的覆盖，很重要的一点是要提供云的基础能力，其中很关键的能力：弹性、多租户、自服务、按需付费，当然这有很多前提，比如你要弹性得公司有资源才行，按需付费也得公司想搞计费才行，但如果要做系统一定要想好，我们后续万一要搞混合云呢？
1.4.4 运营
关于运营的理解，运营在运维这侧我目前理解就是维稳、降本、提效，稳定性应该是运维根本，运营的主要目标应该是后两个。
降本是指的平台可以通过一些机制去确定降低运行成本，其中典型的体现就是业务使用资源是否合理，无论是在k8s还是传统的vm，都有个问题就是研发申请了了4h8g的机器，真的合理嘛？如果我们可以建立一套运营标准，比如我们可以根据业务在过去周、月、季度、甚至年的资源使用，通过统一的标准去衡量其资源使用率，那有没有可能降低一些成本呢？
提效可能是很难衡量的一个指标，因为没办法做一个平台之后，就说自己比之前提升了多少，更多的是可能是从用户使用平台到底需要多长时间，比如上线应用，从应用创建、资源申请、线上交付一共花了多长时间？比如如果公司提供统一的脚手架，脚手架关联标准化建设，打通CI、CD、监控、日志、安全等等功能，那研发是不是只需要从git上拉下项目，然后进行代码开发，最终上线的时候，申请下资源即可？
当然这只是笔者的想法，也没有实践，感兴趣的可以一起聊聊想法，毕竟这个可能比AIops这些可能更容易落地一些。
1.5 选择的困惑
其实不论是在效能还是Paas中，我们都有在做同一件事情，就是应用的全生命周期管理，但是我们会发现不同方向、不同公司的应用定义绝对是千差万别，而且针对应用全生命周期托管没有统一的规范，而且大多数公司的运维研发团队规模都并不大，如何设计出高内聚、低耦合、可扩展、分布式的应用Paas平台，发际线估计又要高不少。
在当下云原生时代，大家可以基于k8s的Paas(Saas)云原生的能力快速构建公司的容器云平台，我们可能会自己搞个App然后结合Service、DEployment等资源去描述一个应用，然后针对日志/监控等进行改造适配，其实大家潜移默化的就在遵循共同的一种标准，其实就是k8s提供给你的，但是针对应用依赖，比如mysql、redis这种信息怎么描述呢？针对中间件这种又该怎么描述呢？这就是今天的主角OAM
2. OAM初识
OAM 全称是 Open Application Model，从名称上来看它所定义的就是一种模型，同时也实现了基于 OAM 的我认为这种模型旨在定义了云原生应用的标准。
- 开放（Open）：支持异构的平台、容器运行时、调度系统、云供应商、硬件配置等，总之与底层无关
- 应用（Application）：云原生应用
- 模型（Model）：定义标准，以使其与底层平台无关
该段描述引用自宋老师的文章，参考附录1
这里我说说我的理解，我们做平台的都会有个痛点就是千奇百怪的设计，几年没动的停机可能起不来应用，谁特么都不敢动，而基于Model，我理解就是，翻滚吧牛宝宝，当然更大的目标肯定是大家有同一个标准，同一个梦想，而且拥有统一的视角。Open开放有两层含义，1）支持异构：我们通过标准的模型声明，接纳云、虚拟机、物理机、容器不同的基础设施，这意味着我们可以无限的扩容我们的平台 2）云原生时代，我们可以复用各种基础设施，让小作坊，也可以体验下五星级酒店的感觉，通过复用云厂商、开源社区可以让我们平台无缝享受开源社区的能力， 接下来让我们一起看看OAM是怎么实现这边目标
2.1 Component
Component是应用组成的一部分，通常由开发进行描述，如下部分都可以描述为一个Component:
1.研发将自己的程序打包成一个镜像，通过Deployment部署
2.研发声明需要使用一个4核8G的mysql5.7的数据库
这两个描述都是component,简而言之研发可以描述的都可以称为Component，因为他们都是组成Application的一部分，这个部分的Model体现主要是体现在我们通过Component的标准化，可以让研发只需要关注极少数的需要知道的东西，就可以完成一个应用在研发角度的定义
在这一层我理解基础设施团队提供给研发定义应用的能力，研发只需要根据应用需要声明对应的component组件， 而并不关注底层的基础设施具体的实现
2.2 Trait
Trait则是运维和基础架构服务化的能力提供手段，运维可以根据应用的描述，来给应用加对应的Trait，那什么可以称之为一个Trait呢？比如弹性扩缩容可能是一种Trait，日志可能是一种Trait、监控可能也是一种Trait，几个实际Trait:
1.研发上线一个java应用，运维这边根据标准化和服务化能力，就会自动加入对应的监控，这其实就是监控的服务化能力
2.应用灰度发布，发现问题，主动进行回滚，这其实是发布系统服务化能力的体现
通过运维能力的输出， 研发就不需要关注底层的各种运维细节，只需要声明应用想拥有的能力，就可以通过实现底层应用运维的自动化托管，不需要关注底层的任何细节，而且各种运维能力可以自由组合，实现应用稳定高效的运行
2.3 Policy
Policy实际上是Component中的概念，体现的其实是研发诉求，比如研发提出我的应用需要响应延迟在100ms以内，那运维就可以根据这个Policy结合自己的服务化能力，提供对应的Trait, 研发其实并不需要知道运维是如何保障SLA的，只需要提供研发诉求Policy，其实就可以完成诉求传递，一切可描述，可度量
研发通过声明Policy传递诉求，运维根据诉求结合运维能力，提供对应的保障，一切都是数据化的，既是运维服务化能力的体现，也是研发和运维彼此信任的良好桥梁，同时研发也并不需要关注各种底层的细节
2.4 Application Scope
应用边界中我们首先要理解边界，边界主要是定义具有某些意义的一类应用的边界，比如在公有云环境中，通常会根据VPC网络划分边界，通过统一的网络配置，可以划分出多个网络区，这些都属于Application Scope。更复杂的场景则是多数据中心，快速止损，当前大多数公司为了灾备都会有多个数据中心，那其实每个数据中心都会划分为一个边界，如果发现某个中心突然挂掉了，即对应的Application Scope下面的
而且ApplicationScope可以任意组合，我们可以通过这种玩法，将要进行某一类的应用进行统一的管理，关注其对应的状态，进而结合我们的Trait来实现各种场景的建设
2.5 Application Configuration
上面我们声明了组成应用的component, 同时附加了运维的Trait， 还通过AapplicationScope,划分了对应的网络或者应用层的边界， 这些组件都是独立声明，可以独立进行演进，实现了应用接入配置的标准化、模型化、松耦合、自由装配，剩下的一步就是通过Application Configuration去将Conponent、Trait、ApplicationScope等组合起来，即就是我们最终的应用声明，基于这份声明结合面向终态的设计，OAM会按照规则分别进行各个组件的托管，同时我们也可以复用社区优秀的Component和Trait来实现平台的快速交付
3. 小结
OAM虽然并没有标准化，但是相信未来一定很美好，笔者现在也在进行这方面的工作，不过目前仅仅是设计调研阶段，欢迎大家一起交流公司平台建设上面的问题以及各种场景的解决方案，文中的理解仅仅是个人的一些理解，阿里大佬们在推动OAM方面做了很多的努力，在接下来几篇我会介绍下OAM的更多的东西，感兴趣的可以持续关注下，附录里面都是阿里大佬的分享，大家多多关注，今天先到这，下期再见