將應用程序遷移至云計算平臺上運行，除了流行之外，本質上還是有具體的好處。

當你打算在云端計算平臺上開發自有的應用程序時，有兩種選擇。第一種是選擇在所謂的IaaS（Infrastructure as a Service）層次上，而第二種則是在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應用程序在擴展系統規模時，我們時常可以看到的情境。