OAM:云原生时代的应用PAAS模型

随着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属于建设过程中的一个阶段，主要强调的是整合。