云计算和DevOps间的关系到底是什么呢：难道DevOps真的只是“针对云的IT”？只能在云中执行DevOps？只能通过DevOps运行云？针对这三个问题，其答案都是否定的。云和DevOps是相互独立的，但在通过IT交付商业价值上却是相辅相成的。

要想真正理解云与DevOps之间的关系，应该退一步在两者是如何发生的大背景下去考虑，这样会有所帮助。云和DevOps的演变是对三个基本社会变革的回应。首先，我们正在经历从产品经济到服务经济的演变。人们更多地强调体验，而非具体事物。尽管公司依然生产各种产品，但是他们将其包装于服务中。BMW一辆新车的价格包含了日常维护。凯迪拉克也将OnStar服务集成于它的车辆中。而iPhone的优势则主要来自它对iCloud和iTunes的集成。

从产品到服务的转型也同样影响着软件交付。以前，开发公司完成软件产品后，就直接交付给用户去负责运营。而随着云计算的到来，大部分公司在构建软件的同时，也负责为客户运营该软件。

软件即服务正发生于IT产业的各个层面。在底层，基础设施即服务交付随需而变的虚拟机、网络和存储。平台即服务交付随需而变的数据库、缓存、工作流引擎和应用程序容器。软件即服务交付按需分配的业务功能。在每个层面，供应商允许客户根据需求购买相应服务，然后根据消费来支付费用，同时也将管理责任交给供应商。

第二，21世纪的商务环境迫使公司将他们的注意力从稳定和有效转变为敏捷和创新。变革的速度不断加快。Kodak鼎盛了100年才开始面对它在市场上的衰弱。相反，Microsoft仅在30年后就感觉到其地位的动摇。而Apple在短短几年后，其作为世界最有价值公司的称号就遭到质疑。

为了向市场展示其应变能力，企业需要改变它们的工作方式。它们需要缩短工作周期，增加交付频率，以及采取支持持续试验的态度。社交媒体正在将主导力从生产商转移到消费者身上。营销也从行为驱动流程转变成对行为的回应。当公司即整体转变为关注单个员工时，公司需要鼓励具有创造性的回应，尽量减少阻碍其前进路上所造成的浪费。

第三，数字层面已经开始完全渗透到物理层面。你的车到底是由金属和塑料，还是Pandora音乐服务客户端组成的？你的办公楼是HVAC系统在流体动力学上一个奇迹，还是大数据的一个奇迹？你的当地图书馆是个需要去真正书架上找书的地方，还是可以上网查看的地方？这三个问题的答案当然都是双重肯定的。

数据渗透极大地提高了IT的赌注。我们已经到了所有日常行为都离不开数字化技术的程度。公司的任一一个存在都需要依靠IT。在为持续业务提供令人信服的平台上，IT无法承担其失败的后果。

拥抱敏捷

以上这些转型与云或DevOps有什么关系？云是对敏捷需求的直接回应。最初，人们主要认为云是一种省钱方式，将资本支出（CapEx）转移到了运营支出（OpEx）。现在，人们发现云的真正价值在于：减少那些会阻碍速度、或让我们失去焦点的浪费。只有很少一部分公司将数据中心业务视为其核心价值主张的一部分。云服务允许IT部门将他们的注意力从繁重的日常工作中解放出来，比如：管理硬件或给操作系统打补丁，从而让他们有时间和精力去创造那些更有特定商业意义的价值。

从产品经济到服务经济的转变同时，伴随着数据化的入侵，这意味着公司在成为软件服务提供商的同时，也要变成消费者。现在，我有99%的银行交易都是通过银行网站或移动应用来完成的。我会通过这些数据交易的质量来判断其品牌好坏。同时通过功能性，可操作性和交付能力等来评价这些交易质量。而在这三点上，我期望其质量能达到无缝结合。

Cloud通过让IT基础架构更加地灵活，从而为商务带来了更大的灵活性。它允许公司与客户间建立起数据化的服务关系。尽管如此，IT在如何让企业实现自我适应这一问题上，Cloud只是原因之一。对于IT企业，不管它是在数据中心硬件上，还是在私有或公共云上运行应用程序，都需要与商业需求同步，而非反之而行，让商业需求与IT同步。基于仓储（Silo）的组织和各种手动流程依然产生各种浪费，阻碍了交付持续更新和进行持续试验的能力。繁琐、费时、无关痛痒的变更管理流程同样也让人生厌和沮丧，迫使用户和开发人员等一起寻求能绕开IT的方法。

IT运维部门（IT Ops organization）总是不幸地被冠上“拒绝部门（The Department of No）”的绰号。在以前那些受挫的商业人员也将此昵称赋予了开发团队。敏捷开发运动大大加强了商业和开发之间的相互信任关系。尽管敏捷为我们带来了各种新的趣味，但是它也有它的不完善之处。从根本上讲，敏捷是调整开发，让其更易去接受，而不是加强它对变化的抵抗力。

功能和可操作的不可分割性

从DevOps角度开看，软件即服务的最重要意义在于其融和了功能和操作性之间的分离。让用户体验到它们之间是整体的、无缝链接的。客户在期待功能和操作性的高质量的同时，也期望服务供应商能在该质量平台上为他们提供持续的更新。

这些期望要求一个完全不一样的软件交付方式。将开发从运维中分离出来与由外到内不可分割的观点相冲突。功能+操作很自然地与开发+运维相对应。DevOps正是由此而生。DevOps所代表的致力为软件即服务各环节建立起相互的信任关系，与敏捷为软件即产品所作出的努力是一样的。敏捷教会开发如何与商业保持相同的速度及灵活性。而DevOps则尽力在教导运维与开发保持相同速度及灵活性。21世纪的成功需要从营销一路到运维，对目标、观点、语言和节奏上有统筹的定位。

Cloud和DevOps不仅仅适用于Web应用

对于那些从事监管行业的IT组织，可以不使用Cloud吗？还有那些主要运营商业软件，而非开发自己产品的IT组织，可以不采用Cloud或DevOps吗？对于这两个问题，答案当然都是可以的。

IT组织从开发到产品的各个层次上都需要灵活的基础架构。集中且共享的开发测试环境会产生大量的浪费，这些浪费来自被污染的测试数据及对资源的竞争。不论私有还是公共的云，IT组织不需要等到有了特定能力才在产品中使用。他们可以使用Vagrant和Docker等工具来改善桌面生产力及共享测试基础设施。

那些管理商业软件的组织也仍然需要协调功能和操作性。他们还是需要稳健、频繁地交付变化，哪怕这些变化包含有业务规则配置。产品支持需要理解变化的总体，包括最上端的商业规则到最底部的基础架构。与其它公司一样，这类组织也能从跨部门协作、全面的版本控制和自动化中获益。

尽管如此，事实上，数字化注入的服务经济很可能会使纯粹的商业应用支持成为过去。随着IT商业价值的不断提升，更多的公司需要在定制开发上有一定的投资，哪怕只是集成或API级别。不可分割的开发和运维实践是普遍通用的。

云计算、敏捷开发和DevOps是推动IT转变为商业适应性策略中环环相扣的几个部分。如果Cloud是个乐器，那么DevOps就是演奏该乐器的音乐家。两个一起为IT完成一重要转变：从询问“我们在崩溃前还能坚持多久？”到“我们多久可以提交一个新功能？”或“我们能多快部署一个新服务？”。

采用Cloud和DevOps

如果你是一个“传统的”IT组织并试图适应新的业务需求，那么你要如何开始Cloud或DevOps呢？你是否需要打破组织结构，或在部署私有云上进行大规模投资呢？持续改进的原则是敏捷、Cloud和DevOps的关键。应该由该原则来指导你的采用方式。持续改进强调的是“从眼前开始”。而事实上，我们也别无它处可以下手。

自适应业务总是在问自己以下这些问题：

从上次到目前为止，都做了哪些修改？

• 如何变得更好？
• 有哪些可以做得不一样？
• 还有哪些没有想到？

自适应IT问得也是同样的问题。对于新的想法或方法论，不再是“我们不能，因为…”这样的反应，而是会问自己：

• 我们为什么不可以？
• 怎样才可以？
• 要到达某一点，需要采取什么步骤？
• 有哪些东西我们应该停止？

这些问题可能会引导你做出以下行动，比如：在一个单一测试环境下体验Cloud平台，或要求信息安全（InfoSec）人员参与到某个项目中去。通过这些行为，你将学到对于你们组织哪些是可行，怎样可行，让你了解如何更广泛地推广云和DevOps。

没有时间浪费

如同一个整体业务,IT也需要进行持续实验。像AWS、ShadowIT这样的公有云,都正在把业务从内部IT部门剥离。为保留控制权而斗争已经成为过去时了。现在IT已经刻不容缓地需要从“拒绝部门”转变成“看护部门”。云和DevOps是两个可行的实践，能帮助IT应对大规模的业务转变，比如：服务经济、持续改进、和数字入侵,从而驱动企业在21世纪的发展。