***效的混合是利用所有组件的有利优势。未来的混合云必须利用公有云的新功能，而且能够保持私有IT投资中的优势。如果你没有考虑数据中的混合需求，企业的风险成本就会直线上升、利益实现问题，甚至是完全技术失败。大多数用户表示云项目失败的主要时间是在计划阶段。正确制定项目计划，才有良好的机会实现成功。
在为了支持混合化设计公有云应用时，有四个因素必须考虑：应用模型、平台、数据库访问以及组件如何连接在一起。
选择应用模型
在为未来的混合化设计公有云应用时，首要考虑的关键因素就是应用模型，不管是前端还是后端模型。企业业务部分报告，他们目前的公有云应用三分之二都是前端模型，在这种模型中云技术加在用户的当前的应用系统之间。这也是互联网零售应用最常用的模型。剩下的大部分企业则关注云爆发或者备份了现有系统的故障恢复应用。
如果你正在为混合化开发一个公有云组件，确保调整当前的架构，适应混合的本地端，或者调整现有的架构适应云端。这些都是你需要在计划阶段解决的，因此在应用的最初需求和未来需求上都要认证考虑。优化混合化最必须的是控制公有和私有组件之间的工作流。你需要支持目前的IT时间，但是你也需要开发唯一的弹性和临时的云属性。
用平台创建和谐关系
技术层面的轻松的混合化的基础就是平台和谐。一个混合云理论上可以通过任何接口集支持工作流，这个接口可以使公有云支持的，也可以是私有IT支持的。在实践中，公有云中有不同的操作系统和中间件，会让事情复杂化，而且变得更加昂贵，尤其是在公有云端的操作支持。
如果你有统一的本地IT架构，就需要认证考虑云端的相同架构。如果你计划一个云爆发或者故障恢复的混合应用，几乎强制性的要使用在云端和数据中心相同的操作系统和中间件。甚至是在构建类Web的前端到当前的IT平台时，要根据性能加强或者随着备份调整架构的一些可能运行在公有云端的关键组件。
让数据库访问公有云和本地IT
在为混合化设计公有云应用时要考虑的第三个问题就是，你如何根据数据需求提供公有云和本地IT资源。存储关键的企业数据到远端设计成本和安全问题，因此大多数用户选择将其数据库保留在本地。因此，当混合应用的云组件必须访问数据时，访问必须跨WAN在云和数据中心之间连接，这样做也是昂贵和性能密集型的方式。
对于云爆发或者故障恢复应用，更适合的解决方案就是使用查询服务数据库管理系统，而不是让云组件使用标准的磁盘I/O方式访问数据库。对于前端应用，可能在当前数据库创建一个逻辑分离更有价值。比如，一个零售的云前端可能使用来源于标准零售库存应用的产品分类，但是不包含库存数量信息；用户浏览静态分类，但是只在订单设置时连接到真正的数据库。
确定应用的“链接”
***的考虑也是最技术的：你的混合应用如何在应用程序接口（API）层面上连接，你的应用如何管理上下文环境或者状态？在软件开发中，组件使用API链接，这些API也通常定义了组件如何追踪他们试图支持的流程。
为混合换开发公有云应用的挑战在于，大多数企业软件基于严格的面向服务架构（SOA）和简单对象访问协议（SOAP）的API。云应用大部分通常采用REST和HTTP架构。不同点在于SOA和SOAP通过多种事务阶段链接组件，而且所有的组件通过其API自动同步其行为。使用REST或者HTTP时，大多数情况下的客户端，浏览器界面追踪上下文环境，这个上下文环境明确地通过这个API交付到每一个组件。
实际的差异在于，任何软件组件的副本访问恰当的数据库可以处理任何REST请求，但是SOA-SOAP请求必须通过最初选择的具体的软件元素处理。REST架构支持简单的附在共享和负载均衡，但是SOA-SOAP中就很难实现。这意味着任何可能包含云爆发或者故障恢复的混合架构要认真考虑REST架构。全端应用可以使用应用组件，运行在云端或者本地，来桥接云端REST或者Web友好的架构和更为传统的数据中心应用架构。
