在前面两部分中，我们详细介绍了如何选择适合你环境的云计算平台，现在我们来看看如何测试并部署这些候选平台。

　　一旦选择了候选云计算平台，您需要确保它们可以达到我们建立的需求。这可以通过对所选的每个候选平台进行深入了解，然后进行测试来实现。

　　我们在第9章“Testing from SOA to the Clouds”中广泛地涉及了测试的内容，所以我们在这里不会讲得太深入。但是，这里的测试与您对云计算平台进行一般的性能有一点不同。具体来说，您会在还没有在那些平台上进行部署前，着眼于云计算平台将怎么支持包括服务、数据和流程的需求在内的架构组件。选择可能是错误的，这也是我们进行测试的原因。

　　对第9章的唯一补充是性能建模和性能测试的使用。模型创建了一个系统在不同类型的负载下如何运行的模拟环境，这些负载通常分为轻型、中型和重型。性能测试确定架构在压力下的执行情况。涉及在内建和基于云的平台上对架构进行建模，信息如何流动，服务如何被调用，以及流动和调用对不同计算资源的影响。您应该对能从一个云计算平台上获得什么样的性能，以及像减少处理能力或者增加带宽对整个性能有什么样的影响，有一个大概的想法。

　　在证实性能模型的同时，您应该使用性能测试，以确定在内建和基于云的平台上，整体架构对业务支持得有多好有多快。此外，测量系统在存储、数据库、流程和服务处理负载不断增加的情况下的执行情况。如果运行得不好，找出其瓶颈：是由于网络？数据库？还是服务？如果有必要，可以和云计算提供商一起来进行修正。

　　选择目标平台

　　一旦我们进行了包括对问题域一个service-、process-和data-级别的理解在内的所有分析，同时已经考虑了安全和治理方面的问题，编制了一个候选系统列表，并完成了验证测试，那么就是时候去挑选云计算平台了。

　　考虑任何有关平台满足架构需求的能力的问题是相当容易的，因此现在业务应该已经众所周知并得到了理解。同时，请记住，很有可能最后对目标云计算平台套装的选择和您最初的设想很不相同，但是如果您自己做了功课并遵循了本书的每一步，它们就是对您架构来说合适的平台。

　　另外值得一提的是，如果由于一些原因，比如错误的调用，或者更加可能地，如果发生了一些与云计算平台相关的业务事件，像云计算提供商歇业或者兼并或者发生更改或者删除了该平台时，从一个云计算平台到另一个平台切换的方便性，或者我们应该说，切换的相对方便性。当然，这取决于您选择的云计算提供商，其使用的标准，以及您找到另外一个提供相似特性和功能的提供商的能力。

　　如果您寻求创建一个使用云计算的SOA的话，业务问题会更重要，既然上面的情况完全取决于云计算提供商保持运营并运行，您需要仔细的考虑：

• 提供商的实力及其为您的云计算平台提供持续支持的可能性。
• 提供商从硬件、软件以及网络故障中动态而且以最少的停机时间恢复的能力。
• 服务水平协议，或者叫SLAs，以及在您和云计算提供商之间，对为架构提供什么样的服务水平达成一致。
• 对云计算提供商的政策以及什么情况下会违背其政策有一个完全的理解。在某些情况下，云计算提供商会在不预先通知的情况下，因为客户违法政策的行为而取消其账户。

　　部署到目标平台

　　这是“就这么干吧”的一步，意味着我们实际地确定代码；迁移数据，创建新的服务、流程以及数据库；并使用本书中的步骤测试和验证所有的服务、数据库和流程是否按照定义正确地工作。

　　这里您应该使用渐进的方法，而不是一个“大爆炸方式的方法”。您应该从最重要的组件开始，依次选择架构的哪个组件应该被移到云计算平台，或者在云计算平台上被创建。

　　当您将这些架构组件移到云计算平台时，要确保它们工作正常，并在继续进入下一个架构组件前，确保已经对其进行了适当地测试。虽然在做一个“大转变”时，会有压力。事实却是，这个循序渐进的方法可以防范问题，同时又没有压倒那些将服务、数据以及流程部署到云计算平台的人。此外，这个方法提供了learn-as-you-go的价值，意味着您有关如何使云计算平台为您架构服务的知识会通过这一过程得到显著地增长。