虽然在某种程度上来说近乎所有的应用都是可以实现云托管的，但是还是有一些具体的设计和开发步骤可以实现云部署的最优化，从而切实推进云计算的发展。如果厂商云厂商们希望实现云计算利益的最大化，那么他们就需要理解云就绪应用的概念，为了云就绪的未来而构建他们的云计算基础设施，并提供便利的服务。
云就绪意味着要解决因云计算之间的差异而带来的问题。从几个重要的方面来说，在虚拟资源上运行的云计算托管应用或应用组件以及这些资源都不同于典型的设备虚拟化数据中心。首先，这些资源是动态分配的，而在大多数的虚拟化数据中心里，分配给应用的虚拟机则基本上都是静态的。其次，它们是分布在一个广域网(WAN)中的，而大多数应用都希望资源能够实现本地连接。再次，它们部分或全部游离于客户的控制范围，这就意味着资源分布和管理是遵循着公共云计算托管厂商所制定的规则，而不是应用用户的规则。
为了适应动态资源分配，云就绪应用必须使用一个正式的DevOps工具用于部署和重新部署工作。在开发应用过程中，应用的架构设计和开发团队必须创建必要的脚本程序或描述符，以定义应用如何映射至它所需的服务器、存储设备以及网络资源。然后操作人员就可以使用这些脚本程序或描述符，把这些应用部署和集成至企业的工作流中。
云厂商们可以用两种方式方便地实现DevOps就绪。其一，他们可以通过流行的DevOps包向他们的云管理系统提供管理连接，以便于帮助用户和开发人员部署云就绪应用。其二，他们可以提供“DevOps即服务”，也就是说他们可以把DevOps工具作为他们云管理平台的一部分进行托管。如果厂商能够组合托管DevOps和应用集成工具(后者能够实现公共云计算资源和企业托管应用及组件的连接)，那么其结果就是现在所谓的集成平台即服务产品了。这不仅为厂商提供了一个新的收入来源，而且还帮助用户开发了云就绪应用，并鼓励开发人员从云部署出发思考如何开发应用。
开发云就绪应用：到底有何不同?
云计算中分布式网络所面临的新挑战
一个分布式网络架构是云计算的另一个独特属性，在云就绪中有两层含义。在第一层，应用所需的网络连接性是其DevOps描述的一个方面。大多数应用都可以作为虚拟LAN而实现虚拟化，并托管一个或多个组件，这些组件可通过默认网关(通常是路由器)与用户相连。创建这一配置是满足部署和重新部署需求的一部分，因此必须在上述的DevOps过程中予以考虑。但是在第二层，分布式服务将影响应用的设计，尤其是在组件化和编排方面。
在分布式网络中，云就绪的重要规则就是避免组件或资源之间的分离，这些组件或资源能够在WAN上形成重要的工作流运动。逐条读写数据库记录是无法在WAN上运行工作流的一个例子，因此云计算中的数据库应当与无论何处都可访问数据库的组件集成在一起。这是一个应用设计的元素。创建云就绪数据访问设计的最常用策略是定义一个数据库管理系统“组件”，这个组件可接受查询(例如以SQL形式)，并针对本地数据库进行处理而只返回一个结果。Hadoop和MapReduce的架构定义也允许对查询处理的云计算进行托管，但不能访问单个数据库记录。
通过提供专为识别低效工作流而设计的云计算应用遥测技术，云计算运营商们可以帮助用户处理与分布式网络相关的问题。他们也可能会提供结构化面向查询的服务，如以软件即服务形式交付的关系型数据库管理系统，或者他们能够提供Hadoop和特定管理工具，帮助把这些服务和云计算应用集成。监控云计算内的流量是找出工作流中问题的最简单方法，但有时知道客户是如何把数据库服务与他们的云应用连接及其结构细节信息，将有助于解决与分布式网络相关的潜在问题。在测试阶段就找出这个问题，将有助于客户坚持在业务中使用云计算。
云就绪应用要求更多的可见性
在云就绪中，最复杂的问题也许就是资源并不在应用所有者的直接控制下。传统的软硬件管理不是被厂商云厂商所篡改就是被他们阉割，厂商的管理接口只能支持某些管理功能。这个问题可以一分为二地看：管理可见性和应用的体验质量控制(QoE)。
厂商并不希望客户有计划在他们的云上安装硬件，所以收集应用和网络性能的管理数据，云计算将不得不并行托管软件元素和应用以便于收集数据并发送至应用用户处，或者厂商云厂商将不得不开放管理接口而允许用户查看性能和状态信息。
大多数厂商厂商都提供基本的管理数据，但并没有提供捕获所有通常管理应用QoE所需数据的机制。这意味着客户不仅将必须试图以对厂商透明的方式收集数据，而且他们必须以某种未知的方法将其与其他网络和应用性能数据整合以管理应用性能和可用性。在选择产品时，不仅要考虑用户使用云计算资源的性能信息，而且要考虑连接至网络的云计算端的网络数据。
云就绪要求应用在云计算中是有意识的。厂商应当认识到，云服务的长期发展趋势将是平台即服务，而在开发阶段更多的云计算托管服务元素将更多地与应用集成。这进一步推进客户业务使用云计算，而他们的预算助推云计算项目和云计算运营商的整体利润。