Puppet和Chef这样的工具帮助人们在云上使用DevOps成为可能，但是当涉及到管理和分析云应用时，仍然会有障碍。

软件开发从一个应用程序的架构开始。传统的应用是单片的，一个承载着业务逻辑的单独载入的镜像运行在一个单独的机器上。但是随着多年来人们对分布式计算兴趣的日益增加，以及易于部署和重用的软件组件化，催生了一种新的模型。

无论你是叫它面向服务的架构（SOA），模块计算还是Web Service，这种新的模型将应用划分成多个部分，然后用工作流接口连接在一起。开发人员必须发送所有的整合和工作流的信息给那些负责部署和管理应用的人员。这种在开发和运维之间的沟通，加上促进这种沟通的流程，在2009年被定义为DevOps。今天，DevOps也指使用实时开发数据来自动化应用部署的工具。

云的DevOps截然不同

云计算正在重新定义DevOps。主要是因为集成的问题，云部署比本地应用部署更复杂。云是一个动态的资源，所以用户期望能够有对故障转移和云爆发的支持。这意味着应用组件和整个应用不会一直在他们初始的位置上。这也意味着工作流和连接会在负载或者一个故障模型操作中变化。于是云管理工具很自然的开始影响，并且也同时越来越多的受到DevOps工具和原则的影响。

有两种常见的DevOps方式：基于脚本和基于模型或对象。脚本模式在前云时代占据主导地位。但是，许多DevOps大牛担心脚本太过程化，只描述了部署和整合的步骤，而不是最终的产品。而一个定义最终目标的DevOps模型需要更多的工作，它可以在各种各样的基础架构和应用组件之间移动，使之更加适合云。

脚本工具在云计算中仍然很常用。但是另外两个工具一直在角逐***的位置：Puppet，展现了一种基于模型或者声明性的脚本撰写方式，另一个是Chef，则采用过程化或者指令的方式。

Chef是一个指令式的DevOps框架，用Ruby来撰写脚本。Chef成为代表DevOps的开发方的强大选项的同时也很难于学习。

然而与Chef不同的是，Puppet对于系统管理员来说通常更加容易学习。Puppet是使用基于JSON数据模型的一种声明式语言。由于Puppet是非过程化的，它成为了DevOps的脚本形式和模型形式之间的桥梁。

云端DevOps的另一大进步是云应用拓扑和编排规范(TOSCA)，一个由行业联盟OASIS制定的开放标准。TOSCA是一个基于模型的架构，将部署和管理定义成抽象的层次化的组件模式属性。其结果是，TOSCA是一个理想的用来描述复杂应用的架构。另外，TOSCA还产生了至少一个开源的实现—OpenTOSCA。

TOSCA对未来的影响比当前的支持更重要。云是关于抽象资源比如虚拟机，虚拟网络和虚拟服务在资源池上的具体实现。这种方法正适合于基于模型的DevOps，并且受到云应用变得更动态的驱使，同时改变了运维和开发。

DevOps背后的推动力

专家们相信敏捷性是DevOps***的推动力。而移动宽带和云计算又接着推动对于敏捷性的需求。一个未来的云应用会是一组连接在一起的组件，几乎可以瞬间对事件进行响应，比如一个移动工作人员，一个无人驾驶汽车或者另一个实时的需求。尽管这些应用也许要更容易建模而不是用脚本，无论何种方式，应用开发和生命周期管理正在演化成更适应云。因此，DevOps应该成为一个业务技术规划流程中的关键部分。

尽管DevOps正以云的面貌不断演化，然而还有一些挑战要克服。比如，一些DevOps工具，即便是***的那些，当用来管理应用执行的时候还是有短板。许多云部署使用一种耦合分析的方法来管理。在这种方法中，云收集信息并提供分析来管理一个资源池，不需要关联到特定应用的特定资源。但是，这对于那些高动态的应用和被用来只是回答某个用户的问题的个性化应用来说可能是个挑战。当管理数据只提供在一段时间内一池的资源信息时，要判断这些应用存在的问题是很困难的。

原文链接：http://www.searchcloudcomputing.com.cn/showcontent_87825.htm