解决方案提供商上门服务：在解决方案提供商最终决定提供哪一种云服务之前，需要获得云计算提供商的类别信息，及其对用户需求的匹配程度。有一些云服务，例如Infrastructure as a Service(IaaS)，是全平台可用的，而另外的一些云服务则有特定的问题，并不能被单独使用。这一篇摘录将帮组您决定，对于您的客户来说，哪一类可以工作得最好。

　　好的，现在我们对问题有了一个data-、services-以及process-层次的理解。我们知道如何去测试，并知道如何进行管理。在第10章，“Defining Candidate Data, Services, and Processes for the Clouds”中，我们解决了哪一个进程、服务以及数据应该采用内建（on-premise）模式，而哪一个应该是基于云(cloud-based)的。现在，我们需要实现最终的物理架构，即选择适当的平台，对那些平台进行测试以确定是否满足我们的需求，在云上移动或者创建进程、服务、数据。

　　这里要记住几件事情。首先，这只是我们架构的一个物理实例。技术会不断变化，但我们的架构应该保持相对的稳定。更何况这还与云计算相关，而改变云计算提供商比改变内建（on-premise）系统更容易而且花费更少。

　　第二，在这最后一步中，我们会选择技术或者云计算提供商。之所以将这个决定保留到现在，是想要在考虑最后几章所遵循的过程里揭示的有价值的信息时保持客观。如果我们在之前已经了解了技术，就可能倾向于使用该技术来进行架构，而这一选择可能是错误的。

　　最后，取决于架构的需要，硬件、软件以及云计算提供商数量的影响可大可小。但不论其数量多少，只需要让我们的解决方案是其中合适的一个就行。根据业务需求以及在这本书列出的最后几步里所做的决定，一些目标架构实例太复杂了，而另一些又太简单了。

　　在这一章，我们着重于架构的云计算部分，包括所有的内建系统和基于云计算的系统。可能您还记得，我们简单地将SOA扩展到了云的平台。我们也必须处理所有内建硬件和软件的问题，包括利用现在的系统，创建新的系统和服务，添加新技术和管理，加入安全，等等。

　　此外，本章对在第一章“Where We Are, How We Got Here, and How to Fix It”中简单涉及到的私有云的概念进行了介绍。私有云是存在于数据中心的防火墙内提供云计算的虚拟硬件和软件资源——像一种更好地利用企业内的硬件和软件资源的能力特征。这也是一种架构的选择。

　　选择平台

　　如您在图11.1中所看到的，能用于满足您架构需求的云计算有许多种模式或类型。其中的一些，如sercurity-as-a-service和testing-as-a-service，用于解决特定的问题，而其它的一些，像platform-as-a-service和infrastructure-as-a-service则提供了完整的平台。他们都有权衡和用于解决的不同问题。但是，您必须根据您的架构对其进行考虑。

　　虽然我们在第三章“Defining the Clouds for the Enterprise”中涉及到了云计算提供商的特征，在这里首先从提供商的粒度开始，看一看它们能对我们的架构符合到什么程度是一个不错的主意。它们的种类包括：

• Storage-as-a-service
• Database-as-a-service
• Information-as-a-service

点击图片即可放大

　　图11.1 允许您在架构中使用一套离散服务集合的云计算提供商的模式或种类。

• Process-as-a-service
• Application-as-a-service
• Platform-as-a-service
• Integration-as-a-service
• Security-as-a-service
• Management/governance-as-a-service
• Testing-as-a-service
• Infrastructure-as-a-service

　　在本文的下半部分，我们可以进一步地将它们分为粗粒度的云计算解决方案，即那些不能单独看作一个平台，可以解决特定问题的提供商，以及粗粒度的提供商，即那些本身就是一个完整平台的提供商。