再谈DevOps实践和价值(12.11)

今天再谈下DevOps过程实践和实际的收益价值问题。对于DevOps先引用网上的一段总结如下。这里我们先分析一下DevOps是什么。大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化，其实这样理解很片面。其实我们不难从Patrick提出DevOps的过程得出结论，DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应，也就是DevOps = Dev Agile Ops Agile。那么我们在重新组合整理下，DevOps就是敏捷管理与软件的持续交付。

从去年开始，我们就一直基于容器化技术加微服务平台在进行DevOps支撑平台的开发和实践，在这个过程中有不少曲折，也有些还没有想清楚的地方，但是这些并不妨碍我们对DevOps过程和价值的理解。

持续集成和敏捷方法论是理论基础

对于敏捷开发和持续集成，在我博客上也写过很多的文章在阐述，敏捷开发的重点是短周期持续迭代，持续集成重点是流水线的自动化，而两者都强调了过程自动化和可视化，更加强调了沟通协同过程的改进，而这些本身也是我们在推进DevOps过程实践的基础。

容器技术是实践落地基础

我们一谈到DevOps支撑过程或支撑平台，一般都会谈到容器技术，可以讲基于 Docker 的容器技术是DevOps支撑过程最终实践落地的基础。通过容器技术才能够更好的实现我们从开发构建到部署，到单元测试整个过程的流水线作业。对于应用来说，完全不用关心具体的物理资源和逻辑资源，只需要按需进行自动化部署即可，这个过程基本在1到3分钟就能完成，极大加快了整个自动化过程的效率。

同时容器技术本身也带来了开发和运维过程的一体化，通过容器化PaaS平台更加容易实现在运行期的资源自动监控和资源调度。

微服务架构和组件化关键配合和驱动力

如果整体应用就是一个大的单体应用，你会发现构建和打包过程再怎样也复杂不到哪里去。但是如果你面对的是几十个甚至更多的微服务模块，同时相互之间还有成百上千的api接口交互，那么整个构建和集成过程的自动化就相当重要了，否则我们需要投入专门的人来处理构建和集成的事务。

由于单个容器本身分配的计算和内存资源都是有限的，如果太大的部署包反而不适合部署到容器里面，因此微服务架构下拆分为更小的组件模块后更加适合结合容器技术进行管理和调度。