将应用程序迁移至云计算平台上运行，除流行外，本质上还是有具体的好处的。

　　当你打算在云端计算平台上开发自有的应用程序的时候，有两种选择：

　　(1)选择在所谓的IaaS(Infrastructure as a Service)层次上

　　(2)在PaaS(Platform as a Service)之上。

　　在这二者之上建构云端应用程序，究竟存在什么样的分别呢?

　　在IaaS上开发：开发者可量身打造所需环境及架构

　　所谓的IaaS平台，像是Amazon AWS(Amazon Web Service)中的EC2(Elastic Compute Cloud)，提供的是运行在云端之上的计算基础设施。这些就与你自己能够建设的计算基础设施没有太大的分别，包括了：能执行应用程序的服务器及操作系统、磁盘存储空间、网络环境、还有可能会需要的软件系统动态，例如HTTP服务器、数据库服务器。

　　但最大的差别是，这些计算基础设施现在都不在你的机房里，而是在“云”之上，你只要刷卡付费，随时都能从“云”上取得这些计算资源，进而将你的应用程序部署上去。

　　对基于IaaS的应用程序而言，开发本身并没有什么太大的不同，使用与之前一样的程序语言、程序库，也用同样的模式开发应用程序。“云”所带来的好处是，计算资源云端化了，由负责管理“远在天边那片云”的供应商帮你处理掉种种的细节，为你带来种种的便利。

　　基于IaaS来发展应用程序的优点是，应用程序开发者有很大的弹性，由于在云端上仅提供最基础的计算资源及环境，开发者可自己针对应用程序的需求，完全量身打造出所需的环境及架构。

　　但是这是一体的两面。当开发者可很有弹性的依据需求，建立自己所需的系统架构，也意谓着，开发者必须自己花费力气去处理与系统架构相关的各种议题。

　　最重要的，莫过于开发者要自己处理和系统规模扩充性有关的各种问题，像是允许系统在需要提升服务的规模的时候，通过增加相关的计算资源(例如服务器、存储空间、内存空间)，便可达到所需的规模。也需要处理各种计算资源的负载均衡以及容错问题。

　　而与系统规模扩充性相关的议题，可说是在建立系统架构时不大容易处理的一个环节。尽管说，在IaaS上开发可得到最多的弹性，但是同时间，开发者需要自行负责的部分也更多，且需要更好的技巧。

　　在PaaS上开发：获得更高端的执行环境，不需处理基础设施相关的细节

　　而在PaaS层次上开发应用程序，与在IaaS层次上开发则有着相当大的不同，这一点，阿里云在其应用开发也是深有体会的。在PaaS上，相较于IaaS所提供的原始设施，它所提供的运行环境，则高端许多。在PaaS这个层次上，主要的目的是要提供一个更高端的执行环境，将诸多与基础设施相关的细节予以封装起来。所以开发者不需要面对如何处理服务器应怎样扩展才能达到应有的服务规模，也不需要考量怎样在众多的服务器之间处理负载平衡、容错的技术议题。

　　开发者所面对的，就是一个被高度抽象化的执行环境，PaaS平台可能提供若干组满足不同用途的API、甚至整合开发环境、各种开发工具，让开发者能据以开发应用程序，但是，开发者无法、也无需碰触到各种系统运行的细节。

　　PaaS平台的提供者，通常都对于建构超大型系统架构有着丰富又纯熟的经验。他们归纳出在大型系统架构上处理系统规模扩展性的经验，进而打造出PaaS层次的云计算平台。其中最典型的例子，当然，莫过于Google了。

　　Google目前主推的PaaS云端平台名为GAE(Google App Engine)。Google强调，当你将应用程序部署至GAE之上运行时，就和Google自有的所有应用程序执行在一样的基础设施之上。

　　可想像的是，原先Google打造这个被人称为“Google Infrastructure”的平台，单纯只是满足自身应用程序所需的超大型全球性系统规模。但他们也注意到，云计算做为如同传统电力设施一般销售的可能性及潜力，于是才以原本仅供自用的计算设施为基础，打造出适合应用程序开发的平台，成了在PaaS层次上的云服务。

　　若是没有PaaS，可问问自己，如果想要扩展系统规模，你可能会考虑投入额外的计算资源，比如说增加主机、增加存储空间、增加主内存、增加网络带宽，但若你的系统架构设计无法通过增加这些计算资源，来扩充系统规模，或者是透过增加这些计算资源可以扩充系统规模，却有其极限的时候，那么你可能就必须设计、建立系统架构。

　　举例来说，我们很常见到的Web应用系统架构，就是前端有一个HTTP的分包器(例如Apache的httpd)，承接来自于使用者端的HTTP协定连线请求，接着将这些连线请求平均地分派到中间层的Web应用程序服务器，而应用程序便执行于Web应用程序服务器之上。应用程序难免需要操作数据，而典型的架构下，数据都存储在后端的数据库服务器上。基于容错或负载平衡的需要，在架构中可能允许一个以上的数据库服务器，彼此之间形成一个群集。

　　当系统的规模不足以应付来自于使用者端的连线请求时，通常扩充系统规模的方式，便是增加中间层的Web应用程序服务器数量。由于一开始，可能是系统缺乏足够的CPU资源或主内存资源，通过增加中间层的Web应用程序服务器数量，便可得到足够的CPU资源或者主内存资源。

　　好的均衡器能承受足够高的请求流量，能平均地将流量导到中间层的各个Web应用程序服务器，并自动侦测出发生异常无法再运作的Web应用程序服务器，进而不再将请求流量导到发生异常的Web应用程序服务器。

　　通过扩展应用程序服务器数量，只能解决一部份存取问题

　　这样看起来很理想，不过有一些问题无法解决。除了容错的机制可能不尽理想之外，这样子的架构，也很难无止尽地通过增加中间层的应用程序服务器，来扩展服务规模。为什么呢?

　　在这种架构下，一开始的确可透过增加中间层的应用程序服务器来扩展服务规模，那是由于一开始的系统能效瓶颈，是在服务器的CPU计算能力或主内存量。但当持续增加中间层应用程序服务器来提升规模之后，慢慢地，系统能效瓶颈便会开始移转。通常，能效瓶颈会移转到数据存取上。由于数据库在系统架构中通常是一个集中化的资源，即使系统中可能有多个数据库服务器，但它们在本质上仍然是集中式。当同时间要处理的数据存取请求够多的时候，集中式的数据库服务器就会变成能效瓶颈，接着就会需要在数据存取的架构上进行各种调整，以便提升能效。这是典型Web应用程序在扩展系统规模的时候，我们时常可看到的情境。