如何将私有云模型拓展到混合云？
私有云是进入混合云的极佳跳板。企业要从私有云模型迁移到混合云需要设定具体的目标。
当企业开始利用服务器虚拟化来提高效率和降低成本，许多公司会很快发现他们正在支持的看起来更像是云计算而不是虚拟化。这些相同的公司中大多数已经使用了公有云资源，他们需要一种新的基于所有资源和数据元素混合化的IT模型。要扩展私有云模型到新的混合数据和处理模型，用户应该建立一个对资源透明的目标，针对这个目标协调数据模型，API和开发实践，使用设计模式来协调应用特定的需求和工具。
虚拟化技术演化为云计算的方式论证了为什么在特定的技术上构建IT规划是有风险的。一个更好的方法是建立在技术透明的基础上，也就是侧重于对服务器和数据资源的抽象化。然后开发人员可以将这些抽象对应到某个特定的方法，而那个方法可以不断进化，因为随着时间的迁移，资源成本和需要都会发生改变。
私有云用户有一大优势，因为他们的内部IT早就已经建立在云的抽象基础上。私有云拓展所需要的一切就是让IT将现有的私有云管理API映射到合适的公有云服务。在许多情况下，私有云规划包括了选择一个云管理系统，其API是和公有云API兼容的或者是公有云选项在私有云API上得到支持的系统。
托管资源透明度的关键需求是基于策略的资源选择，根据成本，可用性等选择公有云和私有云的边界。如果这种能力没有包含在初始的私有云工具集里，IT将不得不考虑增加这一功能。来自HP、IBM、Oracle和微软公司的云工具多半会提供这些功能，但是他们也许会以附加软件包的方式收取额外的费用。
在数据资源方面，透明度的目标是通过识别现今存在的两种独立形式的“数据动态性”。一个是数据的持久性，是否基于实时事务而改变或者以静态意义的方式从历史数据或固定数据库导出。另一个就是数据是否能被动态展示，意味着你可以自动的从数据视图构建网页。
持久化应该是对任何数据库都明确的数据属性，因为持久化的数据可以被更容易的跨云迁移或者被复制来提高使用该数据的分布式组件的性能。数据的动态展示对于暴露数据而不需要撰写自定义的应用来说很有用，自定义应用可能会假设一个特定的数据库位置或者访问级别。开发者应该试图在扩展他们的私有云模型上将这两种形式最大化。
API和应用生命周期管理现在必须要做到最大的透明度。举个例子，需要完全在一个混合云中的公有云部分或之外进行维护的应用程序组件需要被分组为一个虚拟组件并且托管策略之后要加强所需的配置。这也允许开发者在生命周期管理（ALM）的过程中可以正确的测试组件。在某些状况下，这可能需要创建一个fa？ade API来代表一个虚拟组件，这样组件的构成可以随着时间改变，如果需要做一些开发来让资源可以更加灵活的使用。你还可以使用API来提供对于应用来说统一的持久化和非持久化数据的访问。在某些情况下，这些新的虚拟数据模型也可以驱动网页的动态数据生成用于访问和更新。
在数据端的具体策略是确保应用对持久化和非持久化混合数据的访问是被仔细管理的。将应用组件化，这样对事务性或者动态数据的访问会被限制到尽可能少的组件中，因为需要实时数据的组件将可能更难分配为有效的操作。开发人员要对组件中的持久化和非持久化的混合数据API进行仔细管理。
当低层次的API没有提供所有控件开发人员所想要的东西时，使用设计模式（比如外观模式）是一种强大而灵活的方式可以资源透明化。比如，一个被托管在某处的应用程序组件需要访问自己的数据。如果该数据是静态和动态的混合，那么请根据类型上将数据分隔开。如果这个应用组件被移到公有云，请将数据同组件一起移过去这样以便访问。这种抽象数据访问的方法可以帮助组件封装资源的具体细节，这对于开发人员不想要绑定某个托管选项时是很必要的。
如果有必要将云爆炸或者故障转移构建到已有的应用中，设计模式在确保横向扩展和负载均衡分配的一致性的过程中很重要。经验表明试图在每应用的基础上，以资源透明的方式开发会产生各种各样的方案，测试和验证所有这些方法会很头痛。如果每个组件在资源使用上都各行其道，要管理应用到资源的关系也会困难很多。也许需要很多前期的工作来将应用改成用新的设计模式而不是老的API，它可能会从降低ALM和运营的成本并提高资源的敏捷性上迅速得到回报。
云，不管是公有、私有或者混合，都不是最终的目标。真正的目标是独立于资源的应用组件托管。随着云应用从简单的未充分利用的服务器迁移到云进化到特定云的开发，优化平衡私有IT云和公共云所产生的益处将会增加。利用通过新的API和应用模型所产生的透明度的机会也会增加，开发人员和架构师们从私有云到混合云的转变中所学到的将为他们做好迎接IT未来的准备。
