和系统规模扩展性相关的问题，可以说是在建设系统架构时不大容易处理的一个环节。简单的说，在IaaS上开发可以得到最多的弹性，但开发者需要更好的技巧，而且自行负责更多的部分。

　　要将应用程序迁移至云计算平台上运行，可以在两个层次上进行。第一种是选择在所谓的IaaS（Infrastructure as a Service）层次上，而第二种则是在PaaS（Platform as a Service）之上。

　　IaaS提供更多弹性开发

　　在IaaS层次上开发，基本上是将计算的基础设施“云化”。基于IaaS来开发应用程序的优点是，应用程序开发人员在开发时能获得较高的弹性，而且可以自己针对应用程序的需求，完全量身打造出所需的环境及架构。但是，虽说在这个层次上开发最有弹性，但这是一体的两面，这也意谓着所有的软件架构，开发者必须自行建设，而这有时候并不是一件简单的工作，尤其是当你想处理的是系统架构的容错及规模扩展性的问题时。

　　和系统规模扩展性相关的问题，可以说是在建设系统架构时不大容易处理的一个环节。简单的说，在IaaS上开发可以得到最多的弹性，但开发者需要更好的技巧，而且自行负责更多的部分。

　　PaaS提供现成的程序开发与执行平台，平台本身会受到高度专业管理

　　对比之下，在PaaS层次上的优势就浮现出来了。PaaS的提供者，基本上提供的不只是“云化”的计算基础设施，而是“云化”的运行平台。

　　平台和基础设施最大的差别，在于平台提供的是一个更高端的应用程序开发及执行的环境。在PaaS开发、管理、运行应用程序，并不需要、也无法碰触到底层的计算基础设施，这些基础设施都被更高端、更抽象的平台给隐藏、封装起来。开发者在开发时，能运用所使用平台的专用开发工具，包括API、SDK、甚至是整合开发环境。但是，关于系统的规模扩展性、容错、安全性、能效最佳化等问题，都是由平台处理。也正因为碰触不到，所以也无需理会。

　　你可以想像，平台本身是这些问题的专家，由他们来处理这些问题，通常会比你自己处理来得好。

　　运行平台“云”省去了应用程序开发者自行建构平台的力气及时间。大多时候，你可以说这是让更专业的人士、用更集中的资源，去完成平台构建的工作。这些人将焦点放在平台之上，因而能打造出最好的平台，便可以让所有在这个平台上开发应用程序的开发者，都借以得到好处。

　　从这种角度来看，“云”就是一种分工的方式。IaaS提供者所负责的就是基础设施构建、经营、管理的专业及服务，而PaaS提供者更进一步把所负责的范围扩展到平台的层次上。这样的分工下，应用程序开发者可以更专注在本身应用程序的开发，而不需耗费太多成本及资源在应用外的事务之上。

　　免于自建平台或系统架构是PaaS能提供的重要价值。或许当你开始尝试着将应用程序云端化时，首先你遭遇到的问题是计算资源的缺乏。你需要更多的服务器、大量的存储空间、还有更重要的──大量的带宽。利用云端上的计算资源，省时省力又省钱。在一般的系统架构上，你可以解决系统规模扩展的问题。

　　如何克服数据存取上的能效问题

　　可是，慢慢的，当你的系统规模愈来愈大之后，你会发现，并不是靠继续增加计算资源，就有办法继续面对更大的服务规模。因为，系统运作上的能效瓶颈已经不是在这些资源的缺乏，而是源自于系统架构上的限制。这其中最常见到的，莫过于数据存取的效能问题了。

　　许多应用程序一开始的系统效能瓶颈，会发生在各种计算资源的缺乏之上，例如服务器的CPU计算能力、内存容量、存储空间容量、或是网络带宽。不过，随着投入更多的计算资源，这些瓶颈都会被解决，而且到了一定规模之后，瓶颈还会移转到别的地方，而这通常就是数据的存取。

　　就像许多人会采用的系统架构中，都有集中化的关联式数据库。在这样的架构下，无论有多少实体的数据库服务器来做负载平衡及容错，因为关联式数据库的天性，到达一定的规模（无论是服务规模或数据规模）之后，想要扩展其规模，就会变成一件不简单的工作。

　　并不是说关联式数据库不能达到很大的规模，而是，这会需要更为高超的技巧及经验，才有办法做到。这一直都是不容易的技术问题。

　　若是观察一些PaaS层次上的平台，你会发现解决数据处理的规模问题，往往是它们着墨的重点之一，例如Google App Engine上的Datastore,或是Hadoop里的Hbase.

　　当你使用像Google App Engine这样子的平台时，处理永续性数据的方法可以说是只有一种选择，就是使用它的Datastore,而它正是一种非关联式的数据存储方式，之所以要把众多应用程序开发者所惯于使用的关联式数据操作模型，在PaaS的平台上，转变成为仅能使用非关联式数据操作模型，我想主要就是基于规模扩展性的考量。

　　立足于此种平台之上，操作数据的模式，直接就是以处理超大型“海量”规模数据的等级来处理。因为这些平台上所用的数据操作模型及机制，就是能够因应此种规模的数据。

　　因此，当你在这种PaaS平台上来开发应用程序时，如何动态地依据服务规模，来配置相关的计算资源，会由平台自动帮你处理掉、当相关的计算资源发生错误时，平台的容错机制，也会尽可能地协助你的应用程序仍能继续正常运作。而当你所操作的数据规模或服务规模够大时，因为平台所能承受的数据存取规模更大，所以不致于让数据存取成为扩展系统规模时的瓶颈所在。这就是PaaS平台所能提供的助益──让你能真正专注在自己的应用程序上，把平台甚至是程序设计模型的事，都交给PaaS供应商。

　　PaaS平台上的开发限制

　　不过，当你开始着手开发基于PaaS平台的应用程序时，你可能会发现许多技术限制，例如，在Google App Engine上的应用程序，除了HTTP/HTTPS URL存取以及发送电子邮件之外，不能够进行任何对外的网络连线动作，也无法接受来自于外部的网络连线。

　　你的应用程序也无法对档案系统进行任何的存取，甚至你的应用程序不能产生额外的执行绪，而且执行的时间长度还有限制。而且，更重要的是，有些程序设计模型也会受限，好比在前段中所提到的，数据存取的模型可能会受限──只能使用非关联式的数据存取模型。

　　应用程序开发者或许一开始时面对这些限制，会觉得绑手绑脚，甚至觉得很不合理。但是仔细想想背后的原因，就不难明白这些限制，对于要将运行平台云端化，是在所难免的先天本性。

　　运行平台想要云端化就势必进行计算资源的虚拟化，也就是将实体的资源切割成虚拟的数份，让同时运行的多个应用程序，彷佛拥有实体、独立的计算资源一般。因为虚拟化的关系，平台必须确保资源都妥善利用，以便最佳化资源。同时，也不能允许应用程序对其他的应用程序产生干扰，甚至衍生安全性的问题。

　　我们可以说，这些限制都是平台必须做的，否则，在虚拟化的前提下，就无法善用资源，也可能会存在安全性的问题。

　　虽说在PaaS上开发应用程序会有这些限制，但也因为有了这些措施，平台才有办法做到它想提供的种种技术上的好处。