私有云的实施瓶颈往往阻碍了混合云的实施。一个开发运营的思维模式可以让企业用户在缺乏私有云承诺的情况下实施混合云。

    几乎每一家公司都能够从公共云服务中找到好处，但是他们中的大多数却无法证明私有云的价值。很多企业已经实现了数据中心的虚拟化，但是似乎他们并没有看到更进一步的需要。这些企业在专用服务器上运行关键任务应用程序，这也正是这些应用程序最适合被部署的所在。混合云似乎是一个可行的解决方案，但是其中的私有云部分却仍然是一个障碍。那么，如果一家企业在缺乏私有云实施保障的情况下实施了混合云计算，情况又会如何呢？这是可能的——甚至比你想象的更容易。

    混合云实施的一个瓶颈一直就是私有算实施。传统的混合算就是公共云和私有云的简单组合，其中缺少了两者之间的服务流程编制和自动化。但是，一些企业正在使用云友好的集成方法来整合公共云应用程序组件和那些仍部署在数据中心中的组件。而开发运营工具使得这一切成为了可能。

安装任何的应用程序，尤其是基于混合云的应用程序，从传统意义上来说都分为两个阶段，即：部署和集成。在部署阶段，应用程序组件的副本被安装在它们将运行的服务器上。在集成阶段，应用程序组件被互相连接并连接至应用程序的用户。当你实施云时（无论是公共的还是私有的），部署阶段是会变化的，而集成却是保持不变。通过让你的内部部署数据中心资源保持在你的内部，你就可以降低实施混合算的混乱。

开发运营工具节省时日

    IT部门通常都会为应用程序部署选择灵活的开发运营工具——无论云的内外。诸如Chef和Puppet这样的工具适合各种各样的云管理系统，它可允许管理员选择最好的公共云服务。但是，他们通常都忽略了这一点，即这些工具同时部署和集成了应用程序组件；部署工作是不必在云中实施的。如果使用了开发运营工具，那么混合云应用程序中的私有云部分是否真的驻留在私有云中就不再那么重要了。

1. 开发运营工具能够让企业充分利用公共云的所有好处且不会改变实施私有云的内部IT方法。这样做有三个好处：
2. 很多关键任务的应用程序是很难被迁移至云的（甚至私有云），具体原因有二。其一，相关软件是为专用服务器应用而设计开发的。其二，应用程序的性能和稳定性需求是最适合专用服务器和存储资源的。混合这些应用程序而不把核心组件移至私有云可让一整组新的应用程序获得云的好处。
3. 运行在较旧的软件平台上的应用程序可能是难以迁往私有云。当这些应用程序能够简单地如常运行时，混合云的业务案例就能够得到提升。

为了运行一个私有云，企业组织需要拥有一些原本并不具备的工具和技能。此外，你的企业可能并不拥有足够的IT人员或技能来创建一个高效的私有云资源池。通过公共云服务和内部非云组件的混合，就能够消除这一点。

混合云计算消除私有：如何实现

    为了在没有得到私有云承诺的情况下充分利用好混合云计算，可查看应用程序的工作流程以确定应用程序的哪一个组件可迁往公共云。通常，这些组件是应用程序的前端。所以，你需要为这些应用程序开发云部署实践。

第二个步骤就是使用工作流程把应用程序组件部署过程从组件和用户的集成过程中分离出来。从混合的角度来看，部署的目的就是创建一组可供组件定位的目录项。同时，集成的目的就是通过这些目录项的线程连接来移动数据。不要混淆这两者是非常重要的，或者当你每次变更你的云供应商或者内部IT平台时，你将不得不重新进行一次你的所有应用程序生命周期管理（ALM）过程和工具决策。

    混合内部非云组件和公共云服务的最大问题在于，在按需或故障转移场景下实现组件跨云边界的弹性迁移。出于内部安全性或合规性方面的原因，不要计划对那些你不允许在公共云中运行的组件实现云托管。以其他的方法处理那些需要内部运行的应用程序组件的可靠性、可用性和可扩展性。

    当你试图对你的内部部署应用程序组件实施云化时，请务必记得以下原则：在开发运行和ALM实践中把集成和部署分离开来。组件部署不同于对其托管位置的依赖，但是如果你确信云和非云部署的流程代表每一个部署组件的目录项轨迹时集成是相同的。集成仅适用于此；只要云和非云部署都导致产生相同的集成目录项，那么你就可以使用相同的方法和工具来执行集成。