云原生背景下DevOps发展趋势是不是AppOps?

InfoQ上最近有篇翻译自国外的文章，标题是《DevOps 已死，AppOps 长存》，个人感觉这篇文章还是有点标题党，但是仍然进一步说明了DevOps的一些发展趋势。今天就这篇文章内容做下个人的一些理解。

在这篇文章里面实际我们找不对对AppOps这个概念的完整定义，首先摘录一段对为何是AppOps的描述如下：

AppOps 优势体现得最明显的场景之一就是基于 Kubernetes 的应用程序。如果你打开一个个集群，你会发现很多 pod/service/deployment 设置大体都是一样的。事实上，每个 PHP 应用程序都有相同的配置，只有参数不一样。Java、.Net 或其他应用程序也是如此。问题是 Kubernetes 对主机应用程序的内容是不可知的，因此它需要将所有细节都告知应用。

即便用的技术都是一样的，我们也必须从头开始处理所有新的应用程序，为什么？

我本应只解释一次 PHP 应用程序的组成方式。而且我不该浪费时间来定义 PHP 应用程序的部署方式，因为世界上所有的 PHP 应用程序基本上都是相同的，我希望有人（可能是供应商）向社区提供一次正确的配置来重用。假设有一个可重用的配置。你就只需要简单地开发应用程序就够了，无需再费力做那些重复性任务，不再重新发明轮子。此外，你还可以专注于真正重要的事情，不用操心什么细节。

大家注意看下这句话实际强调了两点，其一是AppOps本身是基于Kubernetes 的应用程序，其次是开发人员在开发和集成过程中可以使用标准固化的模板配置，而不用去关心构建部署的底层技术细节。

在这里为个人理解AppOps本身就是DevOps的部分内容，或者说是DevOps持续集成交付的一个发展趋势。AppOps核心就是基于应用的快速交付，开发者的重心应该是在应用开发上面，对于集成，部署，交付都应该是由DevOps平台来完成。

这样说，可能还是难以理解。

拿我们自己的DevOps支撑平台来讲，这个平台本身基于大量的开源工具集进行了上层的集成和整合，实现了完整的从代码管理开始的，开发，编译，构建，打包，部署，生产环境交付的完成集成交付。同时还是集成了代码安全检查，自动化测试等各种管控能力。

但是这个平台本身面向开发人员，同时还需要有一定的持续集成经验，Docker容器和Kurbernetes使用经验等。因为整个流水线的设计和编排是由开发人员完成的。因此开发人员需要去创建编译任务，构建任务，打包任务，部署任务等，同时将这些编排和组合为一个完整的持续集成流水线。

包括对于打包中详细的Dockefile编写，我们也开放给开发人员自己完成。

也就是说底层的持续集成技术支撑，容器云资源池的支撑对于开发来说还是可见的，这种非透明方式的好处就是足够的灵活，但是肯定是带来了一定的学习成本，牺牲了一定的易用性。或者间接来说仍然让开发者关注到了底层的计算支撑和IT资源层的基础设施。

1.重心上移，不需要关注持续集成的技术细节

也就是说AppOps的核心你可以理解为应用开发者重心全部在应用开发和交付上，而对于持续集成的技术实现细节并不需要关心。

我只需要告诉平台我的源代码分支，Maven的构建完成，关键的配置文件和环境变量信息即可。其它所有的编译，构建，集成，部署，生产环境交付等事项我都不需要去关心底层的技术实现细节。

在谈云原生的时候，经常会谈到云原生的一个核心就是整个重心不断地朝上抽象，从资源层到服务层，从服务层到应用层。那么在这个抽象过程中，对于底层的技术支撑，服务支撑细节最好也能够逐渐地做到透明化。

比如前面谈到的我们用Java开发一个应用，只要我是满足标准的Java应用开发标准和接入规范，那么我只需要将应用代码开发完成并Check in就可以了。其它事情我不并需要关心，包括你究竟如何部署的，是否是采用容器部署的，底层动态资源调度如何实现等，这些都不是开发者应该去关心的事情。

不同的开发语言，开发框架当前已经基本成型，也有逐步固化的开发模式和最佳实践，我们要做的就是将标准化的东西尽量通过模板固化，让开发者能够简单的配置就能够完成持续集成和交付过程。

比如前面谈到的流水线设计同样的道理。

我们可以给出几种我们已经配置好的流水线模板，开发者只需要简单选择采用哪个流水线进行持续集成和交付即可。其它后端如何集成，如何支撑开发者不需要关心。

2.完善的技术服务订购使用自服务支撑

对于第二点，在当前主流的云原生，微服务开发思路下实际出行两个关键变化。

首先对于微服务开发，前面多篇文章我都在谈，微服务开发和微服务治理必须分离，开发者只需要关注微服务开发过程，关注业务功能和逻辑的实现。而对于交付完成的微服务模块如何治理这件事情，开发者不需要关心，应该对开发者透明。

这也是我多次强调基于ServiceMesh服务网格思想，通过和Kurbernetes容器云集成，在自动化部署的时候动态下发Sidecar边车的模式将成为一个核心趋势。

简单来说还是你只要按照标准的开发标准和接入规范进行微服务开发，那么你最终开发完成的微服务交付到云原生环境后将自动具备微服务治理能力。

其次，对于云原生下强调的是从资源到服务，不是简单的应用托管和部署，更加重要的是类似数据库，消息，缓存，文件等各种技术支撑能力你都需要自己去构建，而应该是使用云原生PaaS平台的技术服务能力。

因此在整个持续集成中不仅仅是简单的应用编译构建和部署，更加重要的是你开发的应用如何订购和消费已有的技术服务能力，如何和各种技术服务能力集成和融合为一个整体，如何实现开发的应用和底层各个技术服务的纵向协同集成。

这个集成过程要做到足够的自服务化。比如对于Redis缓存服务来说，虽然我现在不用去申请虚拟机资源自己安装和配置Redis集群环境，可以直接使用缓存服务。但是下一步就是我使用缓存服务这个过程要足够自服务，缓存服务的一些底层技术细节我也不需要关心，我重点需要了解的仅仅是缓存服务开发的OpenAPI能力接口。

因此新的DevOps平台发展趋势一定是需要更加方便，快速，自服务的方式打通和各种技术服务的集成和协同工作，并屏蔽底层技术集成细节。

最后总结

没有必要单独又引入一个AppOps的概念，实际上AppOps本身就是属于DevOps的一个子集，同时也是DevOps发展的趋势和能力延伸。当谈DevOps的时候我们重心在持续集成和交付上面，但是最后你会发现当面向业务系统开发者的时候，我们最终需要的还是一个能够实现各种自服务能力的完整PaaS服务能力平台。