可以想象，任何设想进行混合云开发的用户最终都需要完成很多个这样的项目，所以首先制定一个可以应用于所有项目的实施策略，然后在一个合适的混合部署中测试这个实施策略将是十分明智的做法。为了实现成功的混合云实施，这样的一个实施策略必须考虑混合云应用的任务，使用混合云的缘由，以及混合运行与应用体验特质（QoE）之间的重要相互作用。
云计算应用规划者可能犯下的最严重错误就是，在考虑综合、集成或者云计算平台选择这样的技术问题时不为应用本身设定一个应用环境。应用的设计始终主要是由任务而非技术推动的，但是项目任务书则必须正确地综合考虑业务问题和技术要求两方面的因素。
云计算应用的方方面面应用是可以实现多维度分类的。它们可以是事务性的，或者涉及信息传递（第一维）。它们可以是移动的，而不是基于桌面系统的（第二维）。最后，它们也都可以是基于会话或者基于实例的（第三维）。在所有这些维度中，第一个选项要比第二个选项需要更多的设计关注。
在第一个维度中，事务性应用的功能是那些记录或修改信息，这就意味着它们必须在与相关数据进行交互时具有较高可靠性，以避免造成数据损坏的危险。提高可靠性的要求意味着混合应用的公共云计算组件必须具有较高的可靠性，或者必须采取特殊的编程措施（例如分两个阶段提交数据）以保护数据的完整性。如果你将在云计算爆发或故障转移应用中使用混合云，那么事务性应用就需要在任何规模改变或故障转移活动期间维护数据的完整性。
相反，信息传递应用可容忍故障或响应时间变化；如果第一次请求丢失，那么用户将需要重复提交一次请求信息。这就意味着，诸如负载平衡这样的简单技术将支持应用的弹性缩放以及工作任务在公共云计算与数据中心之间的转移。
在第二个维度，移动性会在两个方面带来需要特别关注的问题。第一，移动连接是通过无线网络建立起来的，因此其连接可靠性通常要比桌面系统的连接可靠性更低。这一点将加剧事务性应用中数据完整性问题的恶化。移动用户也可能是在多个可变的环境中工作的，而公共云计算服务可能是由一个单一的数据中心提供的，这样一来就会带来明显的性能差异。如果用户的分散度较高，那么就需要寻找区域托管的服务供应商。
基于会话或基于实例的应用的问题（第三维度）是指用户是否会与应用进行长期的多步骤交互，而不是短期的单次交互。协作是基于会话交互的一个示例，而简单处理一次信用卡购买的业务就是基于实例应用的一个例子。
在应用设计中有一种趋势，即面向会话的应用会通过一个所谓的Stateful行为依赖于一个可靠的一致性连接。大部分面向实例的应用（例如网络应用）是无需维护与一个用户的多阶段对话的环境的（这些被称为Representational状态转移或 stateful应用）。综合Stateful应用要困难得多，因为如果一个组件发生云计算爆发或云计算故障转移，应用就会丢失一个进程中用户活动的相关信息。
可以实施综合的原因可以是因为动态组件调度或前后端现有的云计算组件应用。动态调度意味着在云计算或在数据中心内根据工作负载或者是否有资源失败的实际情况把资源分配给应用组件。
前后端混合应用会在用户和应用的其余部分之间开发一个类似于网络的应用体验，充分利用公共云计算的优势来扩展这些组件或者根据用户的实际物理位置分布把这些组件移动到相应的地域。前后端的方法创造了综合的一个一致性模式，即组件总是在云计算中或在数据中心内，从而简化了设计难度。当需要动态地移动组件时，就会实施所有可以确保用户体验一致性和数据库完整性的措施。
确保高品质的用户体验用户体验一致性是所有混合云设计问题中最具挑战性的一个，其部分原因是因为这个问题具有非常强的主观性和可变性。公共云计算应用体验特性会有显著的差异，这一差异性主要取决于用户相对于其相关云计算托管点的位置，云计算托管相对于数据中心组件的位置以及所有这些位置的网络连接质量。
通过使用可用性区域的方法来管理托管发生位置，以及通过确保云计算爆发或故障转移的动态调度过程中不会产生可能在事务性应用的stateful行为中引入延迟的应用错误，就可以非常容易地解决混合云应用的应用体验特性问题（即确保用户永远不会离基于云计算的组件太远）。
混合云应用设计的最后一点就是客户端设备以及托管在其中的任何本地软件的角色问题。当应用体验特性比较糟糕时，客户端软件可以管理“用户-应用”的交互以防止用户通过重新提交申请而产生多个更新。而在发生云计算爆发或故障转移过程中，它还有助于重新同步应用会话或交易。
如果你在你自己的混合云应用开发过程中遇到过上述的大部分设计问题，那么你可能需要考虑采用一个专业设备应用来配合云计算应用的其余部分。反之，这样做将提高系统的稳定性和用户的满意度。